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SECTIOH  1  Introduction 


1.1  Purpose 

The  purpose  of  this  technical  report  is  to  present  the  advanced 
capabilities  developed  for  the  Communications  Support  Processor  (CSP) 
during  the  previous  year  and  to  discuss  the  impact  these  capabilities 
will  have  on  the  system  and  its  users. 

1.2  Scope 

This  document  covers  the  following  aspects  of  CSP: 

o  a  descriptive  discussion  of  those  enhanced  capabilities 
developed  and/or  analyzed. 

o  a  discussion  of  system  support  tasks,  including  installation 
support,  configuration  management,  software  quality  assurance 
and  software  maintenance. 

1.3  Report  Organisation 

The  CSP  technical  report  is  organized  into  four  sections. 
Section  one  serves  as  a  general  introduction  to  the  CSP  system:  its 
development,  incorporation,  goals,  and  status.  Section  two  describes 
the  CSP  capabilities  and  accomplishments.  Section  three  itself  consists 
of  three  parts.  Part  one  of  section  three  details  the  technical 
performance  of  the  CSP.  Included  in  this  discussion  are  the  following: 
operating  system  upgrade;  hardware  configuration  analysis;  message 
distribution  clerk  analysis;  multiplexer  interface  analysis;  history  and 
intercept  capabilities;  ancillary  control  processor  analysis;  automated 
message  recall  and  retransmission;  and  direct  software  interface  to 
AUTODIN.  This  second  part  also  describes  the  CSP  system  support 
functions.  They  include:  CSP  installation  support;  configuration 
management;  software  quality  assurance;  computer  programs;  and  software 
maintenance.  The  second  part  of  section  three  details  on-site 
maintenance  at  those  CSP  sites  which  have  elected  such  support.  The 
third  part  of  section  three  includes  a  description  of  all  deliverables 
included  under  this  phase  of  the  CSP  Enhancements  Contract.  Finally, 
section  four  summarizes  all  conclusions  and  recommendations  for  the  CSP. 

1 .4  Background 

1.4.1  Initial  Development 

The  Air  Force  Intelligence  Service  (AFIS),  Directorate  of 
Intelligence  Data  Management  (IND)  is  manager  of  the  Air  Force 
Automatic  Data  Processing  System  (ADPS)  for  Intelligence  Data  Handling 
Systems  (IDHS)  -  better  known  as  ADPS-90.  The  ADPS- 90  manager  uses  the 


CUBIC  program  as  an  orderly  and  systematic  approach  for  developing, 
implementing,  disseminating,  maintaining  and  supporting  certain  common 
software  for  use  by  Air  Force  and  other  qualified  agencies/activities 
that  use  AN/GYQ-21(V)  minicomputers. 

CUBIC,  the  Common  User's  Baseline  for  the  Intelligence  Community  is 
a  centralized  management  program  for  software  design,  development, 
maintenance  and  control,  aimed  at  eliminating  redundant  software  efforts 
by  providing  a  set  of  standard  systems/subsystems.  CUBIC  has  also  come 
to  be  known  as  the  software  architecture  philosophy  used  in  managing 
these  software  systems.  The  CUBIC  philosophy  entails  active  user 
determination  of  functional  requirement  priorities,  centralized  software 
development  and  maintenance,  emphasis  on  modular  software  design  lending 
itself  to  transportability,  and  software  design  that  can  be  adapted  to 
meet  site  specific  needs. 

The  CSP  was  developed  at  Headquarters  Strategic  Air  Command  (SAC)  as 
part  of  the  Operational  Intelligence  Support  System  (OISS).  In  June 
1978,  the  CSP  was  tested  under  the  provisions  of  DoD  Manual  5030.58  and 
accredited/certified  by  Defense  Intelligence  Agency  (DIA)/Def ease 
Communications  Agency  (DCA)  as  a  DSSCS/GENSER  AUTODIN  automated  message 
processing  exchange  (AMPE).  The  CSP  has  been  operational  at  HQ  SAC 
since  September  1978. 

1.4.2  CUBIC  Incorporation 

AFIS/IND  as  the  USAF  ADPS-90  manager  was  aware  of  other 
intelligence  user  requirements  to  automate  Special  Security  Offices 
(SS08).  Therefore  in  late  1978  AFIS  adopted  CSP  as  a  CUBIC  entity. 
This  meant  that  CSP  could  be  supported,  for  various  Air  Force 
requirements  and  dovetailed  with  the  HQ  SAC  effort  to  provide  a  single 
software  baseline.  CUBIC  CSP  was  installed/accredited  at  HQ  MAC  in  May 
1979  and  has  been  operational  since  June  1979.  Subsequently  CSP  has 
been  installed  under  the  CUBIC  program  at  PACOM  Data  Services  Center 
(PDSC),  Hawaii  and  at  the  U.S.  Army  Training  and  Doctrine  Command 
Facility  (TRADOC)  TCATA,  Ft.  Hood,  Texas. 

In  February  1980,  a  working  group  comprised  of  representatives  from 
DIA,  AFIS,  RADC,  SAC,  and  PDSC  recommended  to  the  Assistant  Secretary  of 
Defense  for  Command,  Control  Communications  and  Intelligence  (C3I)  that 
CSP  be  adopted  as  an  interim  standard  for  Special  Security  Office  (SSO) 
Fixed  Base  Teleconsunications  automated  message  handling  systems.  This 
recommendation,  which  was  subsequently  approved,  included  appointment  of 
AFIS/IND  as  executive  agent  for  life  cycle  management  of  CSP  software. 
In  November  1980,  the  Director  of  DIA  and  the  Air  Force  Assistant  Chief 
of  Staff /Intelligence  signed  the  official  CSP  executive  agent  agreement. 
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1.4.3  Contract  Goals 


The  contract  goals  were  established  to  provide  the  following 
accomplishments  in  a  timely  manner: 

o  CSP  Operating  System  Upgrade  -  This  included  determination  of 
the  modifications  required  to  convert  the  CSP  operating 
system  to  RSX-11M+. 

o  CSP  Hardware  Configuration\-\This  included  an  analysis  of  the 
modifications  required  to  facilitate  migration  of  the  CSP  to  a 
smaller,  less  expensive  hardware  configuration,  such  as  the 
Digital  Equipment  Corporation  (DEC)  PDP-11/24. 

o  Message  Distribution  Clerk\-\This  task  included  an  analysis  of 
the  feasibility  of  optionally  supporting  the  Message 
Distribution  Clerk  (MDC)  functions  via  a  single  screen  CRT 
device  conforming  to  DODIXS  criteria  for  standard  alphanumeric 
terminal. 

o  Multiplexer  Interf ace\-\This  task  included  an  analysis  of  the 
capability  to  optionally  interface  to  all  communications  and 
peripheral  devices  currently  supported  by  the  baseline  CSP 
(independently  of  the  BR1569  or  BR1731  multiplexer)  by 
utilizing  off-the-shelf  vendor  interface  devices. 

o  History  and  Intercept  Capabilities\-\This  task  included  an 
analysis  of  the  capability  of  the  CSP  to  optionally  provide  the 
system  history  and  intercept  capabilities,  utilizing  disk 
recording  media  versus  magnetic  tape. 

o  Ancillary  Control  Processor\-\This  task  included  an  analysis  of 
the  capability  to  utilize  the  DEC  Ancillary  Control  Processor 
(ACP)  concept  to  improve  processing  efficiency  and  reduce 
memory  requirements  for  the  CSP  baseline  system. 

o  Message  Recall\-\This  task  included  an  analysis  of  the  software 
required  for  the  CSP  to  enable  automatic  message  recall  and 
retransmission  to  designated/controlled  lines  based  upon 
communications  interfaces  to  the  CSP. 

o  Direct  AUTODIN  Interface\-\  This  analysis  examined  the 
feasibility  and  work  required  to  develop  an  interface  to  the 
AUTODIN  ASC  using  only  software  independently  of  special 
AUTODIN  interface  devices  such  as  TLC,  AID  or  INTEQ. 
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CSP  Site  Support \-\This  involved  six  phases  of  CSP 
installation:  Preinstallation  support;  installation 

configuration;  software  installation,  test  and  checkout;  user 
familiarization  and  training;  enhancement /update  distribution; 
and  installation  configuration  management. 

o  Tra ining\-\This  dealt  with  providing  training  at  the 
contractor's  facility  (or  on-site)  for  site  communications 
operators  and  programmers,  as  required  to  support  installation 
of  the  CSP.  Additionally,  training  materials  were  provided  to 
the  users. 

o  CSP  Software  Inventory \-\A  software  inventory  had  to  be 
maintained  of  all  CSP  software  modules  which  can  be  configured 
into  a  CSP  based  system.  A  site  unique  inventory  must  also  be 
maintained  for  each  site  with  CSP  software  installed. 

o  AFIS  Support\-\A  central  repository  for  the  processing  of  all 
system  enhancements  and  problem  reports  must  be  maintained. 
All  site  unique  requirements  must  be  evaluated.  Each 
enhancement  must  be  reviewed  upon  completion,  and  when  accepted 
by  the  Air  Force  and  made  part  of  the  baseline,  shall  be  made 
available  to  all  sites. 

o  Software  Engineering\-\A11  computer  software  delivered  in  the 
course  of  this  contract  shall  be  implemented  in  accordance  with 
RADC  Software  Development  Specification  CP  0787796100E,  dated 
30  May,  1979. 

o  Configuration  Management\-\This  task  ensured  adherence  to  well 
defined  procedures  for  implementing  additions  or  modifications 
to  the  CSP  standard  system. 

o  Software  Quality  Assurance\-\This  task  resulted  in  the 
development  and  implementation  of  a  Quality  Assurance  Plan. 
This  assured  compliance  with  all  software  requirements  of  the 
contract. 

o  Computer  Programs\-\The  objective  of  this  item  to  ensure  that 
the  most  current  version  of  all  CSP  software  was  delivered  to 
AFXS/IND  for  distribution. 

o  Software  Maintenance\-\This  task  included  work  which  provided 
centralized  maintenance  support  for  all  CUBIC  sites. 

o  On-site  Maintenance\-\This  task  provided  on-site  software 
maintenance  support  to  sites  requesting  this  level  of  CUBIC 
support. 
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1.4.4  System  Statu* 


The  CSP  has  been  in  operation  for  over  5  years.  Since  its 
initial  operational  date  in  September  1978,  the  system  has  compiled  an 
impressive  record  of  accomplishments.  CSP  down-time  is  recorded  in 
terms  of  minutes-per-veek;  it  has  proven  itself  to  be  highly  reliable 
in  terms  of  protecting  secure  traffic;  and  it  has  never  lost  a  message 
as  a  result  of  system  design  or  software  deficiencies. 

CSP  Release  I  as  implemented  at  HQ  SAC  in  1978  was  derived  from  the 
DIA  SPINTCOM  facility  software.  However,  functional,  security  and 
hardware  changes  required  a  60Z  rewrite  of  the  original  system. 
Moreover,  the  current  architecture  bears  little  resemblance  to  SPINTCOM 
design.  CSP  Release  II  as  implemented  under  CUBIC  auspices  may  almost 
be  considered  third  generation,  since  many  changes  to  improve 
modularity  and  transportability  have  been  made.  As  a  part  of  the  CUBIC 
program,  the  CSP  has  been  installed  on  a  variety  of  different  hardware 
configurations;  and  as  a  result,  has  become  a  modular  system,  readily 
configurable  for  installation  into  various  environments. 

CSP  is  currently  installed  at  twelve  locations  representing  the  Air 
Force,  Army  and  Navy.  Applications  range  from  a  full  teleconmunications 
center  automation  system  to  a  front  end  processor  for  an  analyst  support 
system. 
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SECTION  2  Communication  Support  Processor  System  Description 

2.1  Functional  Description 

The  Cosanunications  Support  Processor  (CSP)  is  a  computer  system 
designed  to  automate  the  functions  of  a  Telecommunications  Center  (TCC) 
and  serve  as  a  communications  front-end  processor  for  analyst  computer 
systems.  It  can  best  be  described  as  a  collection  of  application  and 
system  level  computer  programs,  designed  to  execute  as  a  coordinated 
whole,  for  the  express  purpose  of  accomplishing  store  and  forward 
operations  of  record  copy  message  traffic.  The  primary  tasks  of  the  CSP 
system  consist  of  reception  of  message  traffic,  validation  of  proper 
format,  determination  of  required  routing  and  delivery  to  the  intended 
recipients. 

Regardless  of  size,  each  TCC  is  served  by  a  "standard"  CSP 
configuration  as  depicted  in  Figure  2-1.  However,  the  components  which 
comprise  the  standard  system  will  vary  to  meet  the  operational 
requirements  of  the  organization  served. 

The  standard  system  consists  of  a  basic  AN/GYQ-21(V)  system  with  the 
following  components:  CPU,  memory  (minimum  192K),  system  console,  two 
800  BPI  tape  drives,  two  80MB  disk  drives,  line  printer,  appropriate 
communications  interfaces.  Analytics  TLC-100  or  equivalent,  and  one  or 
more  Univac  1652  (0J-389)  terminals.  Software  required  for  the  standard 
system  is  the  CUBIC  CSP  baseline  package  and  the  latest  version  of  the 
IAS  operating  system. 

2.2  Summary  of  Capabilities 

CSP  can  best  be  described  as  a  collection  of  application  and 
system  level  computer  programs,  designed  to  execute  as  a  coordinated 
system,  for  the  express  purpose  of  store  and  forward  operations  on 
record  copy  message  traffic.  While  there  are  many  ancillary  functions 
of  CSP,  its  primary  task  consists  of  reception  of  message  traffic, 
validation  of  proper  format,  and  determination  of  required  routing. 

In  and  of  itself,  CSP  is  merely  a  message  management  system. 
Stripped  of  all  ancillary  processing,  CSP  is  a  system  which  reliably 
moves  data  from  one  point  to  another.  It  is  this  ancillary  software, 
however,  that  defines  the  characteristics  of  the  data  being  moved,  and 
that  operations  are  performed  along  the  way. 
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Figure  2-1  Optimum  CSP  Hardware  Configuration 


Some  of  the  basic  functions  and  capabilities  provided  by  CSP  are 
listed  below: 

o  Mode  1  AUTODIN  R/Y  Interface 

o  Mode  II  Interface  Support 

o  Variety  of  Interfaces  and  Protocols  Supported 
o  Input  and  Output  Security  Check 

o  Message  Format  Validation 

o  Message  Journalization  and  Audit  Trail 

o  Message  Review  and  Dissemination 

o  Routing  Line  Segregation 

o  Classification  Stamping  of  Hardcopy  Output 
o  Message  Edit /Generation 

o  Output  Message  Logging 

o  Alternate  Message  Routing 

o  Online  Message  Retrieval 

o  Real-time  Status  Display 

o  DD  Form  173  support  with  Plain  Language  Address  Expansion 
o  Fully  Automated  Routing  and  Dissemination 

2.3  Sii— ry  of  Development  Accomplishments 

A  detailed  description  of  the  work  performed  on  each  of  the  SOW 
items  is  presented  in  Section  3  of  this  technical  report.  This 
paragraph  serves  as  a  summary  of  these  developments. 

Several  analysis  tasks  were  undertaken  during  the  first  phase  of 
this  work  effort.  These  included  operating  system  upgrade,  hardware 
configuration  analysis,  OJ-389  and  multiplexer  interface  alternatives, 
history  and  intercept  capabilities,  ancillary  control  processors, 
automated  message  recall  and  retransmission,  and  Direct  AUTODIN 
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Interface  analysis  tasks.  This  resulted  in  the  publication  of  numerous 
technical  reports  which  were  made  available  to  all  CSP  users  for 
comment . 

Four  of  these  analysis  efforts  resulted  in  a  decision  by  the  users 
either  to  delay  the  capability  or  not  to  implement  it  at  all.  These  are 
the  operating  system  conversion  to  RSX-11M,  implementation  of  ACPs, 
implementation  of  automated  message  recall  and  retransmission  based  on  a 
service  message,  and  the  replacement  of  the  TLC100  with  a  software 
interface  to  ADTODIN. 

Several  others,  however,  did  result  in  the  development  of  a  new 
capability.  These  were  all  in  the  form  of  an  option  to  the  user  as 
opposed  to  a  replacement.  For  example,  the  user  has  the  option  of  using 
either  an  OJ-389  or  a  Delta  Data  8252T  terminal.  Additionally,  the 
alternative  will  exist  to  use  either  a  BR1569/BR1731  multiplexer  or  the 
new  DVll  multiplexer  software.  A  major  new  capability  that  also  uses 
this  philosophy  is  the  history  and  intercept  functions.  The  user  now 
has  the  alternative  of  operating  with  two  disks,  a  disk  and  a  tape,  or 
two  disks  and  tape.  This  approach  allows  a  great  deal  of  flexibility  in 
configuring  a  system. 

This  fiscal  year  also  saw  the  installation  of  two  new  CSPs,  at 
USAREUR,  Heidelberg,  Germany  and  at  DSAFE  TFC,  also  in  Germany.  Several 
site  surveys  were  also  performed  which  is  an  indication  of  the  number  of 
new  sites  which  are  projected  for  the  near  term  future. 


SICTIOI  3  Technical  Performance  and  8upport 

This  section  discusses  all  actions  taken  or  underway  which 
involve  technical  analysis,  development  or  support.  The  results  of 
these  actions  may  be  the  completed  development  of  the  desired  capability 
or  the  publication  of  a  technical  report  detailing  the  steps  which  will 
be  necessary  to  develop  that  capability. 

Subsections  below  describe  the  task,  outline  the  objectives  of  the 
effort,  detail  specific  accomplishments  and  provide  a  discussion  of  the 
impact  of  development  efforts  on  the  CSP  system. 

3.1  SOW  Tasks 

This  section  describes  all  those  tasks  identified  in  the  Statement 
of  Work  for  the  CSP  Enhancements  Contract.  These  tasks  include  analysis 
and  development  of  advanced  capabilities  as  well  as  CSP  support  items. 

3.1.1  Operating  System  Upgrade  (SOW  4.1.1) 

3. 1.1.1  Objective 

The  objective  of  this  task  was  to  determine  the  feasibility 
and  impact  of  converting  CSP  to  the  RSX-11M+  operating  system  from  the 
currently  used  IAS  version.  IAS  has  been  a  reliable  operating  system, 
capable  of  operating  in  any  one  of  three  modes:  real-time,  multiuser, 
or  time-sharing.  However,  Digital  Equipment  Corporation  (DEC)  has 
projected  discontinuance  of  support  for  IAS  as  early  as  1986.  In 
addition,  IAS  is  36  percent  more  costly  to  install  than  the  RSX-11M+ 
version. 

The  analysis  was  directed  towards  weighing  the  advantages  that 
might  be  obtained  by  conversion  to  RSX-11M+ ,  including  I  &  D  space 
support.  Supervisor  Mode  Libraries,  and  improved  I/O  performance; 
against  possible  disadvantages  such  as  having  to  rewrite  all  handler 
code  and  possibly  experiencing  adverse  user  impact  during  conversion. 

3.1. 1.2  Accomplishments 

Informatics  completed  an  analysis  of  CSP  conversion  to  the 
RSX-11M+  operating  system  by  April,  1983  and  presented  its  findings  in 
Technical  Report  83-43110-05,  "Communications  Support  Processor 
Operating  System  Upgrade  and  Hardware  Configuration  Interim  Technical 
Report".  This  document  discussed  the  advantages  and  disadvantages  of  a 
system  upgrade,  concentrating  on  the  incompatibilities  between  IAS  and 
RSX-11M+.  Addressed  areas  were:  device  handlers,  directive 
differences,  utilities,  SYSGEN  procedures,  performance  considerations, 
hardware  considerations,  and  user  impact. 
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3.1. 1*2.1  Device  Handlers 

The  analysis  of  an  operating  system  upgrade  highlights  the 
fact  that  under  RSX-11M+  device  handlers  are  treated  as  processes 
within  the  Executive,  rather  than  separate  tasks  as  is  the  case  under 
IAS.  An  advantage  of  this  difference  is  that  the  Executive  does 
validation  of  a  request  before  passing  the  request  on  to  the  handler. 
Some  reduction  in  code  in  the  handlers  themselves  is  also  achieved, 
since  the  Executive  determines  the  type  of  request  and  sends  it  to  the 
appropriate  point  in  the  handler  software. 

Because  handler  tasks  are  privileged  tasks  under  IAS,  and  CSP  uses 
these  directives  frequently.  Informatics  concluded  that  considerable 
effort  would  be  necessary  to  accommodate  these  differences  in 
developing  the  code  conversion.  Handlers  unique  to  CSP,  such  as  the 
Bunker  Ramo  multiplexer  handler;  the  Univac  terminal  pseudo  handler; 
the  DDCMP  pseudo  handler;  the  DV-11  handler  and  the  CSP  handler 
interface  to  the  message  file  would  all  require  a  complete  code 
rewrite.  This  effort  would  involve  approximately  22,000  lines  of 
MACRO- 11  code  over  an  extended  time. 

3. 1.1. 2.2  System  Directive  Differences 

Numerous  system  directive  differences  exist  between  IAS  and 
RSX-11M+.  While  approximately  35  new  system  directives  would  be 
available  under  RSX-11M+,  14  have  been  deleted,  including  some  used  by 
CSP.  Another  37  system  directives  have  been  modified  and  perform 
differently  between  the  two  operating  systems. 

It  should  also  be  noted,  as  indicated  in  the  Technical  Report,  that 
Monitor  Console  Routines  also  differ  under  RSX-11M+.  Most  involve  the 
addition  of  MCR  commands  or  renaming  the  commands.  Four  commands  are 
deleted  under  RSX-11M+: 

o  MEM  -  unlocks  tasks  from  memory  which  were  locked  by  the 
Executive  due  to  a  memory  parity  error. 

o  PWD  -  change  or  create  a  password. 

o  OTL  -  allows  user  to  set  parameters  for  timesharing  scheduler. 

o  WHO  -  indicates  which  terminals  are  logged  on. 

3. 1.1. 2. 3  System  Utilities 

The  enalysis  determined  that  the  utility  routines  remained 
basically  the  same  under  RSX-11M+  with  the  exception  of  the  Volume 
Preservation  Utility,  PRESRV.  This  utility,  normally  used  to  save  a 
system  disk  or  master  disk,  allows  the  user  to  create  copies  of  volumes 
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to  disk;  magnetic  tape;  DECtapes  or  cassette  tape.  Unlike  DSC  or  BED 
under  IAS,  PRESRV  copies  all  blocks,  including  bad  ones,  to  or  froa  the 
selected  medium. 

3.1. 1.2.4  STSCn  Procedures 

Several  features  associated  with  the  RSX-11M+  operating 
system  enhance  the  system  generation  process: 

o  Full  Functionality  Executive.  Options  available  allow  use  of 
numerous  features,  such  as  shadow  recording,  resource 
accounting,  console  driver  support,  batch  processor  support, 
virtual  terminal  support  and  others. 

o  Autoconfiguration.  Under  the  proper  conditions,  this  feature 
will  automatically  determine  the  correct  hardware 
configuration  of  the  host  system.  SYSGEN  procedures  are  also 
facilitated  because  SYSGEN  uses  the  results  of  the 
Autoconfiguration  to  answer  the  Choosing  Peripheral 
Configuration  section. 

o  SYSGEN  Menu.  This  feature  allows  the  system  user  to  resume  a 
partially  completed  SYSGEN  at  a  specified  section  or  to  perform 
selected  individual  sections  of  the  generation. 

3. 1.1. 2. 3  Performance  Considerations 

Three  characteristics  of  the  RSX-11M+  operating  system 
provide  features  which  would  be  beneficial  to  system  performance.  Of 
the  three,  the  improved  I/O  speeds  available  with  the  upgraded 
operating  system  are  the  most  significant.  Hardware  that  utilizes  the 
new  Digital  Storage  Architecture  (DSA),  such  as  the  UDA50  Controller 
and  the  RA60/80/81  disk  drives,  are  supported  by  RSX-11M+.  High  data 
handling  rates  (3Mb/Sec),  high  density  recording,  improved  seek  times, 
and  simultaneous  operations  to  all  system  disks  are  possible  through 
control  of  the  intelligence  resident  in  the  UDA50.  A  second  feature, 
virtual  terminal  support,  eliminates  the  need  for  a  physical  terminal 
for  communications  between  the  system  and  the  job  being  performed. 
Thirdly,  supervisory  mode  libraries  can  effectively  expand  the 
available  usable  memory  by  allowing  mapping  into  the  Supervisor  Mode  I 
&  D  space. 

3. 1.1.2. 6  Hardware  Considerations 

Although  RSX-UM+  will  support  an  extensive  hardware  suite 
not  supportable  through  IAS,  there  are  many  listing  equipments  that 
cannot  be  supported  by  RSX-11M+.  Among  the  latter  are:  the  LA30, 

LA33,  and  the  VT30  family  of  console  terminals;  the  RK05,  RPR02, 
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RX01/2,  and  RM04  disk  drives;  the  TD60  and  TS03  tape  drives  and  the 
CDA11-A/E  card  readers;  along  with  many  of  the  cooson  disk  controllers, 
tape  controllers,  clocks  and  communications  devices. 

3. 1.1. 2. 7  User  Impact 

Although  conversion  to  the  RSX-11M+  operating  system  would 
present  numerous  advantages,  especially  longevity,  over  the  present  IAS 
version,  the  initial  impact  upon  the  user  community  would  be 
significant,  and  largely  negative.  At  some  sites,  for  example,  such  as 
those  with  both  a  CSP  and  a  MAXI  installation,  both  IAS  and  RSX-11M+ 
would  exist  necessitating  that  the  system  operator  be  familiar  with 
both  systems.  All  conversions  would  require  that  the  site  be 
re-licensed  for  the  new  operating  system.  All  system  operators  and 
on-site  programming  personnel  would  need  extensive  training  in  the  new 
operating  system.  And  finally,  for  a  considerable  period  of  time,  both 
APIS  and  the  contractor  would  need  to  maintain  support  for  both  the  old 
and  the  new  operating  systems  since  not  all  sites  would  be  converted. 
This  dual  management  burden  would  add  to  the  overhead  required  to 
provide  CSP  support  to  all  users. 

3. 1.1. 3  Discussion 

Many  advantages  are  available  through  the  RSX-11M+  operating 
system  which  are  not  available  with  IAS.  These  advantages,  however, 
would  be  gained  only  at  the  expense  of  extensive  software  development 
efforts,  a  heavy  training  requirement,  significant  initial  user  impact 
and  increased  management  overhead.  Indirectly,  another  consideration 
weighs  into  any  discussion  of  an  operating  system  upgrade.  Eventually, 
CSP  software  will  be  converted  to  a  High  Order  Language.  This 
conversion,  like  the  conversion  of  operating  systems,  will  require 
extensive  software  rewriting.  Because  the  prospect  of  two  massive 
software  conversion  efforts  outweighs  the  apparent  advantages  to  be 
gained  by  implementing  the  RSX-11M+  operating  system,  the  Informatics 
analysis  concluded  that  a  decision  on  upgrading  the  operating  system  be 
deferred  until  a  decision  is  reached  concerning  the  High  Order  Language 
question. 

After  a  thorough  review  of  the  Technical  Report  and  Informatics 
recommendations,  RADC  and  APIS  decided  not  to  proceed  with  an  operating 
system  upgrade  to  the  RSX-11M+  version  at  this  time. 


3.1.2  C8P  Hardware  Configuration  (SOW  4. 1.1.1) 
3. 1.2.1  Objective 


The  objective  of  this  task  was  to  determine  whether  CSP  could 
be  modified  to  permit  migration  to  a  smaller,  less  expensive  hardware 
configuration  such  as  the  PDP  11/24  or  similar. 

3. 1.2. 2  Accomplishments 

Analysis  under  this  task  was  supported  by  operational  tests 
conducted  during  January,  1983,  on  a  PDP  11/24  to  determine  the  effects 
of  error  trapping  on  processors  without  odd  address  detection.  The 
results  of  the  tests  and  analysis  were  published  in  Technical  Report 
83-43110-05,  "Communications  Support  Processor  Operating  System  Upgrade 
and  Hardware  Configuration  Interim  Technical  Report",  dated  April  1983. 
The  Technical  Report  compared  various  smaller  DEC  processors  against  a 
PDP  11/70  standard  in  an  attempt  to  identify  the  best  candidate  for 
migration  of  CSP  software.  The  major  considerations  addressed  are  the 
following: 


3. 1.2. 2.1  Instruction  Sot  Compatibility 

The  criteria  for  comparison  of  compatibility  with  baseline 
CSP  on  a  standard  hardware  configuration  (PDP  11/70)  was  the  degree  by 
which  the  assembly  language  of  the  specified  processors  differed.  It 
was  determined  that  the  PDP  11/23  and  PDP  11/24  differed  in  36  percent 
of  the  cases  tested.  For  the  PDP  11/34,  this  difference  was  noted  in 
35  percent  of  the  cases.  For  the  PDP  11/44,  a  difference  of  20  percent 
was  noted,  meaning  that  the  11/44  was  compatible  with  80  percent  of  the 
assembly  language  cases  tested. 

3.1 .2.2.2  Performance  and  Price  Comparison 

All  processors  considered  were  significantly  less  costly 
than  the  11/70,  with  the  difference  most  notable  for  the  11/24.  The 
11/34  and  11/44  have  essentially  equivalent  price  tags  at  the  mid-price 
range. 

Although  a  smaller  system,  the  11/24  has  the  ability  to  access  up 
to  1  Mb  of  main  memory  (248  Kb  standard),  provides  improved  multi-user 
performance,  easy  console  operation  and  optional  Floating  Point 
capabilities  for  improved  FORTRAN  and  BASIC  operation. 

The  PDP  11/34  has  several  features  of  interest.  One  is  the 
self-test  diagnostic  routines  which  continually  check  for  system 
faults.  Another  is  the  automatic  bootstrap  loader,  permitting  system 
restart  from  various  peripheral  devices.  An  easy-access  backplane 
facilitates  system  configuration.  The  floating  point  option  available 
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with  this  system  can  improve  the  speed  of  floating  point  operations  by 
a  factor  of  ten.  Available  also  is  a  cache  memory  capability  which  can 
increase  system  performance  by  up  to  60  percent. 

Features  which  distinguish  the  fourth  generation,  mid-size  PDP 
11/44  include  the  8  Kb,  high  speed  cache  memory  for  fast  execution  and 
improved  system  throughput.  Memory  management  in  the  11/44  is  another 
feature  which  improves  overall  performance  as  well  as  providing 
increased  protection  in  a  multi-user  environment.  Inherent  in  the 
11/44  is  the  ability  to  access  1  Mb  of  main  memory  and  error 
detection/correction  coding  to  assure  high  reliability  of  memory.  The 
Floating  Point  option  for  improved  performance  in  FORTRAN  and  BASIC 
applications  is  also  a  feature  of  the  PDP  11/44;  and  an  option  is 
available  for  a  battery  backup  system,  protecting  data  integrity  during 
power  failures. 


See  the  referenced  Technical  Report  for  a  more  complete  discussion 
of  other  aspects  of  the  comparison  such  as  operating  system  support, 
peripheral  support,  physical  characteristics  and  power  requirements. 

3.1. 2. 3  Discussion 

The  analysis  that  Informatics  conducted  on  small  processors  to 
which  CSF  might  be  migrated  concluded  with  a  recommendation  that  the 
PDP  11/44  be  selected.  This  recommendation  was  based  upon  the  degree 
to  which  the  11/44  could  match  the  11/70  in  performance,  the 
significantly  lower  software  cost  in  converting  to  the  11/44,  the 
acceptable  cost  of  the  hardware  itself,  an  available  memory  capacity  of 
4  Mb  and  the  ability  of  the  11/44  to  support  the  new  Digital  Storage 
Architecture. 

The  Technical  Report  and  the  contractor  recommendations  were  the 
subject  of  considerable  interest  at  the  August  CSP  User's  Conference 
sponsored  by  AFIS  in  Bellevue,  Nebraska,  jith  the  group  consensus 
favoring  adoption  of  the  recommendation  concerning  the  PDP  11/44  as  the 
small  system  alternative  to  the  PDP  11/70. 
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3.1.3  Message  Distribution.  Clerk  (SOW  4. 1.1. 2) 

3. 1.3.1  Objective 

The  objective  of  this  task  was  to  determine  the  feasibility  of 
optionally  supporting  Message  Distribution  Clerk  (MDC)  functions  via  a 
single  screen  CRT  device  conforming  to  DODIIS  criteria  for  a  standard 
alphanumeric  terminal. 

3. 1.3. 2  Accomplishments 

Analysis  of  single  screen  terminals  concentrated  on  one 
example  of  a  "dumb"  terminal,  the  DEC  VT100,  and  one  example  of  an 
intelligent  terminal,  the  Delta  Data  7260T;  although  the  analysis  would 
generally  apply  to  other,  similar  terminals.  Both  terminals  were 
compared  as  to  cost  and  performance  with  the  standard  OJ-389,  dual 
screen  terminal. 

3. 1.3. 2.1  "Dumb"  Terminal  Alternative 

The  approach  taken  under  this  alternative  was  the 
replacement  of  the  current  OJ-389  subsystem  with  a  software  module 
within  the  host  processor  which  would  provide  an  equivalent 
functionality  at  a  DEC  VT100  (or  similar)  terminal.  Such  a  terminal 
could  be  interfaced  to  CSF  by  any  hardware  device  supported  by  the  DEC 
Terminal  Handler  (e.g.,  a  DL  or  a  DV).  The  new  software  module. 
Terminal  Control  Program,  would  support  each  of  the  functions  currently 
performed  by  the  OJ-389  subsystem.  The  light  pen  function  of  the 
OJ-389  would  be  provided  through  direct  cursor  addressing,  so  any 
terminal  considered  under  this  alternative  would  require  this 
capability. 

Two  other  significant  differences  between  the  single-screen  "dumb" 
terminal  and  the  OJ-389  involve  the  dual  screen  handling  and  a 
scrolling  feature.  The  dual  screens  of  the  OJ-389  would  be  retained  in 
separate  disk  files  under  control  of  the  Terminal  Control  Program.  A 
key  on  the  numeric  keypad  would  be  used  to  flip  between  the  two 
screens,  with  the  currently  displayed  screen  being  returned  to  its  disk 
file  (including  any  modifications  made  to  the  contents  while  being 
displayed).  The  other  feature,  scrolling,  replaces  the  "next  page" 
function  and  "previous  page”  functions  of  the  OJ-389.  Both  a  "scroll 
down"  and  a  "scroll  up"  option  would  be  available  at  the  terminal, 
giving  the  user  the  ability  to  move  forward  or  backward  through  a 
message  one  line  at  a  time. 

Message  editing,  dissemination,  manipulation,  generation  and  recall 
features  would  all  be  available  at  the  terminal  with  user  actions  not 
differing  significantly  from  those  on  the  OJ. 
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Section  3.3.3  discusses  cost  comparisons  and  other  benefits  of  the 
"dumb"  terminal  alternative. 

3.1 .3.2.2  Intelligent  Terminal  Alternative 

An  intelligent  terminal  alternative  would  function  more  like 
the  OJ-389  than  would  the  "dumb"  terminal.  The  software  modules  which 
presently  provide  the  interface  to  the  OJ  would  also  be  used,  with 
modification,  to  interface  with  a  single-screen  intelligent  terminal 
such  as  the  Delta  Data  7260T  or  8252T.  The  dual  screen  capability  of 
the  OJ-389,  however,  would  be  provided  through  use  of  the  "split 
screen"  feature  of  the  Delta  Data.  In  conjunction  with  the 
programmable  key  capabilities,  the  split  screen  will  enable  the  user  to 
obtain  an  equivalent  functionality  to  that  of  the  dual  screen. 

Because  an  intelligent  terminal  is  microprocessor  based,  with  its 
own  resident  memory  (18,000  characters  in  the  case  of  the  Delta  Data 
7260T),  message  manipulation  is  handled  without  intervening  reference  to 
the  host  processor.  As  with  the  “dumb"  terminal  option,  a  scrolling 
function  would  replace  the  "next  page”  and  "previous  page"  options  of 
the  OJ-389.  Programmable  Function  (PF)  keys  would  be  used  to  interface 
with  the  host  terminal  software  for  such  features  as  selecting  the  next 
message  on  queue  or  the  highest  priority  message  on  the  queue. 

Message  editing,  dissemination,  manipulation  and  generation  would 
not  differ  greatly,  procedurally,  from  the  familiar  functions  available 
with  the  OJ-389.  The  user  would,  of  course,  have  to  familiarize 
himself  with  the  keyboard  layout  and  the  logical  functions  assigned  to 
the  PF  keys.  One  useful  feature  in  message  generation  is  the 
availability  of  the  "canned"  message  option.  This  option  calls  up  a 
prepared  message  format  by  a  single  depression  of  one  of  the  PF  keys. 
The  operator  or  analyst  may  then  insert  necessary  data,  or  otherwise 
modify  the  prepared  text,  and  introduce  the  finished  product  into  the 
system  with  a  single  depression  of  the  "Send  New  MSG"  key,  another  of 
the  programmable  function  keys.  This  feature  can  greatly  reduce  the 
time-consuming  process  of  creating  new  messages  for  frequently 
recurring  requirements. 

An  intelligent  terminal,  such  as  the  Delta  Data,  offers  other 
potential  advantages  beyond  the  enhanced  operations  related 
specifically  to  CSP.  The  terminal  may  be  expanded  through  the 
addition  of  floppy  disk  drives  to  provide  increased  memory.  Other 
peripherals,  such  as  printers,  may  then  be  added  to  permit  stand-alone 
operations,  if  desired.  And  because  a  terminal  like  the  Delta  Data 
uses  the  CP/M  operating  system,  hundreds  of  application  programs  are 
readily  available,  off  the  shelf,  to  meet  specialized  needs. 


3. 1.3.3  Discussion 

The  technical  report  analysis  cites  benefits  of  alternatives 
to  the  OJ-389  for  use  with  CSP.  Advantages  in  obtaining  vendor 
supplied  software,  in  the  reduced  size  of  the  terminal,  in  the  support 
provided  for  additional  peripherals  and  in  the  functions  available 
within  the  terminal-resident  software  were  highlighted  (primarily  for 
the  intelligent  terminal).  Perhaps  the  most  dramatic  difference,  and  a 
major  advantage  for  the  alternative  terminals,  however,  is  the  cost. 
Purchasers  of  a  VT100,  for  example,  will  obtain  an  87  percent  cost 
reduction  compared  with  the  OJ-389.  Even  for  the  much  more  capable 
Delta  Data  7260T,  the  cost  reduction  still  amounts  to  82  percent. 

For  these  reasons,  and  because  the  Delta  Data  had  been  accepted  as 
a  standard  D0D1IS  terminal  at  the  time  the  Technical  Report  was 
prepared,  the  final  recommendation  concluded  that  the  Delta  Data  7260T 
offered  the  optimal  solution  for  desired  replacements  of  the  OJ-389. 

At  a  subsequent  meeting  during  August,  1983,  representatives  of 
AFIS,  Informatics  and  INCO  discussed  standardization  of  CSP  and  MAXI 
efforts  in  Delta  Data  development.  With  new  information  concerning  the 
Delta  Data  8252T  terminal,  a  more  versatile  version  in  this  series,  it 
was  decided  that  both  CSP  and  MAXI  would  standardize  on  the  8252T. 
Development  activities  on  the  Delta  Data  7260T  were  consequently 
suspended.  The  conclusions  and  recommendations  of  the  Technical 
Report,  however,  would  remain  essentially  the  same  if  the  8252T  were 
substituted  for  the  7260T  as  the  intelligent  terminal  of  choice.  The 
8252T,  in  fact,  compares  even  more  favorably,  since  the  terminal  is 
directly  plug -compatible  with  the  OJ-389,  and  can  be  substituted  with  a 
minimum  of  technical  support. 
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3.1.4  Multiplexer  Interface  (SOW  4. 1.1. 3) 

3. 1.4.1  Objective 

The  objective  of  this  task  was  to  determine  whether  the 
capability  could  be  obtained  or  developed  to  provide  an  optional 
interface  to  all  communications  and  peripheral  devices  currently 
supported  by  baseline  CSP,  independently  of  the  BR1569  or  BR1731 
multiplexer. 

3. 1.4. 2  Accomplishments 

Informatics  conducted  a  thorough  analysis  of  nine  possible 
alternatives  to  the  BR-1569/1731  multiplexers  used  as  the 
communications  interface  to  CSP.  The  results  of  this  analysis  were 
published  in  Technical  Report  83-43110-03,  "Communications  Support 
Processor  Multiplexer  Interface  Technical  Report"  dated  March,  1983. 

The  purpose  behind  the  objective  stated  for  this  task  was  to 
attempt  to  locate  a  less  complex  and  less  costly  solution  to  the 
communications  interface  requirement  for  CSP.  The  old  standard,  the  BR 
1569,  and  the  updated  replacement,  the  BR  1731,  were  designed  to  handle 
a  variety  of  protocols;  making  the  device  unnecessarily  complex  for 
most  CSP  applications,  and  rather  expensive  (typically  in  the  range  of 
$25,000  for  a  basic  16-line  configuration,  and  nearly  twice  that  for 
the  32-line  version).  Further,  the  BR  1569/1731  devices  are  not 
DEC-supported ;  therefore,  require  third  party  maintenance  support. 
Lack  of  DEC  support  also  means  that  considerable  device  handler  upgrade 
support  is  necessary  to  permit  use  of  the  Bunker  Ramo  devices  in  the 
CSP  operating  environment. 

These  factors  led  to  a  decision  to  concentrate  upon  an  analysis  of 
less  costly  multiplexers  that  could  meet  any  or  all  of  the  potential 
CSP  applications  and  would  not  require  extensive  device  handler  support 
or  third  party  maintenance.  The  following  devices  were  selected  for 
analysis: 

°  DL11 .  The  DL11  is  an  asynchronous,  single  line  interface 
which  can  permit  a  PDP-11  to  communicate  with  a  local 
terminal,  a  remote  terminal  via  modems  over  a  private  line  or 
the  public  switched  telephone  network,  or  with  another  PDP-11 
computer. 

o  DZll .  The  DZll  is  a  program-controlled,  asynchronous 
multiplexer  which  connects  a  PDP-11  or  VAX  11/780  to  8  or  16 
asynchronous  serial  lines. 


COMM  IOP-DZ .  The  COMM  IOP-DZ  is  an  intelligent,  asynchronous 
Direct  Memory  Access  line  controller  with  an  auxiliary 
processor  which  relieves  the  CPU  of  the  time-consuming  process 
of  dealing  with  asynchronous  lines  and  terminals. 

DH11.  The  DH11  is  an  asynchronous,  serial  multiplexer  which 
permits  operations  with  up  to  16  individually  programmed 
serial  communications  lines. 

DV11.  The  DV11  is  a  programmable  communications  preprocessor 
which  permits  interface  of  the  PDP-11  with  either  eight  or 
sixteen  synchronous  and/or  asynchronous  communications  lines. 
Character  size  and  format  of  the  sync  lines  are  switch 
selectable  for  each  4-line  group.  Character  size  and  format, 
and  speed  of  the  async  lines  are  program  selectable  for  each 
line. 

DQll .  The  DQll  is  a  high-speed  (up  to  1  Mbit/Sec  in  the 
DQll-EA  model),  double-buffered,  serial  synchronous  PDP-11 
interface  which  permits  the  PDP-11  to  be  used  for  remote  batch 
and  remote  concentrator  applications.  In  cases  where  it  is 
desired  to  use  the  PDP-11  as  a  communication  front-end,  the 
DQll  permits  the  handling  of  local  and  remote  synchronous 
terminals. 

DPP11.  The  DUP11  is  a  program-controlled,  double-buffered 
device  designed  to  interface  the  PDP-11  processor  with  a 
single,  serial  synchronous  communications  line.  The  notable 
characteristic  of  this  device  is  its  ability  to  handle  a  wide 
variety  of  bit  or  byte  oriented  protocols. 

COMM  IOP-DPP .  COMM  IOP-DOP  is  an  intelligent,  synchronous 
line  controller  based  on  a  KMC 11 -A  auxiliary  processor,  used 
to  control  a  DDP11  synchronous  interface  over  the  PDP-11 
UNIBUS.  COMM  IOP-DDP  is  designed  to  implement 
high-performance  communications  network  systems.  It  can 
provide  a  small  but  extremely  powerful  front-end  and  is  ideal 
for  message  switching  applications,  where  high  efficiency  can 
be  achieved  at  substantial  cost  savings  over  the  more 
conventional  methods. 

DMR1 1  .  The  DMR11  Network  Link  is  designed  for 
high-performance  connection  of  PDP-11  and  VAX  computers  in 
network  applications  within  a  single  facility.  The  device  can 
be  configured  for  operation  at  speeds  up  to  1  MBS  over 
inexpensive  coax  cable. 


The  analysis  conducted  by  Informatics  found  several 
alternatives  to  the  BR-1569/1731  multiplexer  which  fit  the  criteria  of 
the  original  objective.  All  of  the  alternatives  examined  were  less 
costly  than  the  BR-1731,  the  only  currently  produced  version  of  the 
Bunker  Ramo  device  used  for  CSP  applications.  However,  no  single 
device  was  found  which  would  fit  the  variety  of  communications  line 
configurations  and  applications  that  CSP  must  serve.  Consequently, 

some  analysis,  selection  and  tailoring  is  required  to  insure  the 
optimal  interface  device  or  combination  of  devices  is  specified  for  the 
desired  use.  The  following  summary,  extracted  from  the  March,  1983, 

Technical  Report,  identifies  those  DEC-supported  devices  which  meet  CSP 
interface  requirements  in  most  configurations: 

The  DZll  and  DUP11  are  modern  devices  which  could  function 

adequately  on  small  systems  with  a  light  traffic  load.  Since  neither  of 

these  devices  perform  DMA  transfers,  the  system  overhead  may  be 
unreasonable  on  a  CSP  system  with  a  moderate  to  heavy  traffic  load. 
Under  these  operating  conditions,  the  COMM  IOP-DZ  and  COMM  IOP-DUP  would 
be  ideal  controllers  for  the  CSP.  These  devices  are  DMA  controllers 
that  consists  of  a  microprogrammed  KMC11  and  single  or  multiple  DZlls  or 
DUPlls  respectfully. 

The  DVll  however,  has  several  characteristics  that  recommend  it  as 
an  excellent  alternate  interface  for  the  current  CSP.  The  DVll  will 
function  with  the  range  of  PDP-11  computers  from  the  PDP-11/24  through 
the  PDP-11/70,  and  will  function  satisfactorily  on  small,  medium  and 
large  CSP  configurations,  it  is  the  only  DEC  multiplexer  that  supports 
both  synchronous  and  asynchronous  lines.  This  extreme  flexibility  of 
the  DVll  is  supported  by  the  fact  that  as  a  single  device  it  will 
support  all  CSP  communications  with  a  single  handler.  Any 
consideration  for  simplicity  would  be  in  favor  of  the  DVll.  In 
addition,  it  is  an  intelligent  DMA  device  that  will  unload  much  of  the 
communications  work  from  the  main  computer. 


3.1.5  History  sad  Intoreopt  Cspsbility  (80V  4. 1.1. 4) 

3. 1.5.1  Objective 


The  objective  of  the  History  and  Intercept  Capability  task  vas 
to  analyze  the  feasibility  of  optionally  providing  a  second  disk 
capability  for  CSP,  and  to  design  such  a  secondary  message  file  support 
capability.  Availability  of  a  second  message  file  would  permit 
additional  options  in  history  and  intercept  capability  other  than  the 
standard  message  file  disk  with  history  tape  configuration. 
Achievement  of  such  an  objective  would  permit  several  enhancements  in 
CSP  operational  efficiency. 

3.1 .5.2  Accomplishments 

Analysis  and  design  of  a  second  disk  history  and  intercept 
capability  were  completed  and  the  results  published  in  Technical  Report 
83-43110-04,  dated  March,  1983. 

3.1.5 .2.1  Current  History  and  Intercept  Procedures 

CSP  requires  dual  recording  of  all  message  traffic.  The 
on-line  message  storage  requirement  for  a  typical  CSP  site  is  30  days, 
with  the  ability  to  meet  these  storage  requirements  being  dependent 
upon  the  volume  of  traffic  at  the  site  and  the  capability  of  the  disk 
used.  History  tapes  are  generally  used  both  as  a  backup  to  the  disk 
and  to  retain  messages  in  longer  term  archival  storage.  The  history 
tape  also  is  used  for  intercept  purposes — the  rerouting  of  traffic  for 
selected  queues  to  the  history  tape  queue  for  later  re-entry  to  CSP  for 
processing.  This  intercept  capability  is  useful,  for  example,  when  one 
or  more  tributary  stations  are  temporarily  out  of  service,  or  when  the 
CSP  host  system  itself  must  be  drained  of  traffic,  as  when  the  system 
must  be  shut  down  for  maintenance.  Upon  system  restart,  active  system 
traffic  is  recovered  from  the  tape  by  message  or  groups  of  messages  and 
processing  proceeds  normally. 

3. 1.5. 2. 2  Disadvantages  of  History  Tape 

The  disadvantages  of  using  tape  medium  for  message  storage 
or  intercept  purposes  are  generally  described  in  terms  of  I/O  speed. 
The  slow  speed  of  the  tape  medium  compared  with  disk  presents  problems, 
mostly  time  related,  both  when  writing  to  the  tape  and  when  it  is 
necessary  to  recover  information  from  the  tape. 
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In  the  duel  recording  process,  redundant  I/O  write  requests  are 
issued,  first  to  the  tape  and  then  to  the  disk.  Because  of  the  relative 
slowness  of  the  tape,  however,  the  write  request  to  disk  is  completed 
well  ahead  of  the  same  action  on  tape.  Therefore,  the  length  of  time 
required  for  any  I/O  action  is  the  time  required  for  the  tape  I/O. 

A  more  dramatic  time  delay  occurs  when  it  is  necessary  to  recover 
information  from  the  tape,  as  is  the  case  when  a  read  failure  is 
encountered  on  the  disk.  Because  the  desired  message  must  be  located 
from  its  place  in  a  sequential  file  of  messages,  recovery  can  be  quite 
a  time-consuming  process. 

3.1. 5.2. 3  Alternatives  to  the  History  Tape 

Until  recently,  searching  for  a  viable,  practical 
alternative  to  the  use  of  tape  for  backup,  history  and  intercept 
purposes  was  not  feasible.  No  practical  alternative  could  match  the 
tape  medium  in  its  three  premier  attributes — large  capacity,  very  high 
reliability,  and  low  cost. 

Recently,  however,  large  strides  have  been  made  in  disk  technology, 
particularly  in  the  three  areas  mentioned  above:  capacity, 
reliability,  and  price.  With  recent  hardware  improvements,  large  data 
volumes  can  now  be  stored  on  small,  relatively  inexpensive  disks. 
Concurrently,  significant  improvement  have  been  made  in  the  techniques 
used  by  CSP  for  recording.  Standard  IAS  operating  system  File  Control 
Services  (FCS)  routines  have  replaced  the  non-standard  methods  formerly 
used  by  CSP  for  disk  I/O,  FCS  employs  rigorous  tools  to  ensure  proper 
disk  space  allocation,  accurate  I/O,  and  efficient  handling  of  I/O 
errors.  The  increased  reliability  these  procedures  provide,  along  with 
cost  reduction  in  high  capacity  disks,  has  effectively  eliminated  the 
comparative  advantage  of  tape  for  large  data  storage  applications.  As 
an  example.  Digital  Equipment  Corporation  has  announced  a  205  megabyte 
cartridge  disk  to  be  used  in  a  drive  roughly  equivalent  in  cost  to  the 
TE16  magnetic  tape  drive;  one  disk  cartridge  for  this  system,  costing 
$600,  would  replace  approximately  $800  worth  of  magnetic  tape.  Larger 
capacity  disk  systems  are  available,  such  as  the  DEC  RA81,  a 
fixed-media  winchester  drive  with  a  456  megabyte  capacity. 
Developments  such  as  these  have  permitted  consideration  of  other 
configurations  as  alternatives  to  the  standard  disk  with  tape  backup 
found  in  the  typical,  existing  installations. 

3.1.5.3  Discussion 

The  referenced  Technical  Report  concluded  that  the  state  of 
the  art  in  disk  technology  has  advanced  sufficiently  to  permit 
configuration  other  than  the  standard  message  file  disk  and  tape 
backup/history  arrangement.  Some  arrangements  which  may  now  be 
considered  include  the  following: 
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Disk/Disk.  This  option  permits  completely  tapeless  operation, 
with  the  message  file  disk  being  augmented  with  a  second  disk 
capability  for  both  backup  and  history/intercept  purposes.  All 
the  advantages  provided  by  the  increased  1/0  speed  of  disk 
operations  would  be  available  to  organizations  with  small  to 
medium  message  volumes,  with  anticipated  reliability  comparable 
to  that  of  present  disk/tape  systems.  Costs  would  not  differ 
significantly  from  the  typical  arrangement,  and  might  well  be 
less. 

o  Disk/Disk/Tape.  Those  organizations  with  a  requirement  for 
longer  term  archival  storage,  and  those  with  larger  traffic 
volumes,  might  well  chose  to  use  a  second  disk  as  a  backup, 
mirror  image  of  the  message  file  disk,  while  retaining  the  tape 
capability  for  history  purposes  only.  Intercept  might  well  be 
to  an  operator-specified  medium,  either  tape  or  disk. 

To  further  improve  system  reliability,  the  two  disk  systems  could 
be  installed  each  with  its  own  controller. 

In  conclusion,  CSP  users  now  have  disk  alternatives  available  that 
provide  capacity,  reliability  .and  low  cost  that  compare  favorably  with 
tape  media,  while  retaining  the  advantages  of  reduced  system  overhead 
and  high  I/O  speeds. 


3.1.6  Ancillary  Control  Processor  (SOV  4. 1.1. 5) 

3. 1.6.1  Objective 

Analyze  the  capability  to  utilize  the  DEC  Ancillary  Control 
Processor  (ACP)  concept  to  improve  processing  efficiency  and  reduce 
memory  requirements  for  the  CSP  baseline  system. 

3.1 .6.2  Accomplistments 

The  analysis  of  this  capability  was  performed  by  examining 
several  publications  by  DEC  and  the  Digital  Equipment  Computer  Users 
Society  (DECUS).  These  publications  were  written  by  users  who  had 
previously  implemented  ACPs  under  the  RSX-11M  operating  system.  This 
provided  considerable  information  on  the  applicability  of  ACPs  to  the 
CSP  system.  It  was  determined  that  although  CSP  could  benefit  from  the 
ACP  technology,  it  could  not  be  implemented  separately  as  it  is  tied  to 
several  other  tasks. 

3.1. 6. 3  Discussion 

The  original  intention  of  this  task  was  to  benefit  from  the 
ACP  functionality . associated  with  the  operating  system  RSX-11M. 
Although  ACPs  are  allowed  under  IAS,  not  as  much  benefit  would  be 
derived  from  implementation  under  IAS  as  would  be  the  case  with  RSX. 
The  decision  not  to  convert  CSP  to  run  under  RSX-11M  or  RSX-11M+,  also 
affected  the  decision  on  whether  to  implement  the  ACP  capabilities. 
ACPs  still  may  be  used  at  some  point  in  the  future  as  new  capabilities 
are  added  to  CSP,  but  it  makes  little  sense  at  this  time  to  rewrite  CSP 
just  to  take  advantage  of  the  ACP  technology. 


3.1.7  Mtiutt  Recall  (80V  4. 1.1.6) 

3.1.7.1  Objective 

The  objective  of  this  task  was  to  determine  the  feasibility  of 
developing  an  automatic  message  recall  feature  for  location  and 
retransmission  to  designated/controlled  lines  of  traffic  identified  in 
formatted  service  messages. 

3. 1.7.2  Accomplishments 

This  analysis  was  successfully  completed  and  a  proposed  design 
for  future  implementation  was  included  in  Technical  Report  83-43110-10, 
"Communications  Support  Processor  Message  Recall  Interim  Report", 
issued  in  August,  1983. 

3.1. 7.2.1  Current  Procedures 

Every  Telecommunications  Center  (TCC)  receives  a  variety  of 
retransmission  requests,  both  verbally  and  via  service  messages. 
However,  when  a  request  is  received  by  the  TCC  Supervisor,  a  search  is 
initiated  for  the  requested  message,  using  references  such  as  Time  of 
Transmission  (TOT),  Date/Time  Group  (DTG)  or  Channel  Designator 
Sequence  Number  (CDSN).  If  an  initial  search  fails  to  locate  the 
desired  message,  the  operator  may  broaden  the  search  by  specifying  a 
wider  TOT  range,  or  may  formulate  a  recall  command  based  on  a  CSP 
Message  Ledger  Number  (MLN)  range  which  he  believes  may  contain  the 
message  sought.  If  the  message  is  located,  the  operator  adds  a  pilot 
to  the  message  and  routes  it  to  the  proper  output  queue.  In  the  event 
that  a  search  fails  to  locate  the  requested  message,  the  Supervisor 
prepares  a  service  message  to  the  requestor  advising  him  that  the 
referenced  message  could  not  be  located  and  that  tracer  action  may  be 
initiated. 


3.1 .7.2.2  Proposed  Recall  and  Retransmission  Procedures 

The  Informatics  analysis  concluded  that  software  could  be 
developed  which  would  implement  an  automatic  recall  feature  within  CSP. 
The  following  steps,  extracted  from  the  referenced  Technical  Report, 
sumarize  the  design  which  was  proposed  to  accomplish  the  automatic 
recall  feature  within  the  CSP  if  APIS  and  RADC  were  to  direct 
implementation. 

o  Strict  validation  of  retransmission  request  service  message 
format. 

o  Testing  for  auto-recall  for  receive  lines. 
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Building  a  PRB  for  SVCCON 
SVCCON  processing. 


I 

o 

o  Scanning  for  possible  recall  parameters, 
o  Building  and  issuing  a  recall  command  line, 
o  Validating  the  new  recall  command  line  parameter, 
o  Preparing  a  PRB  for  RCLCON. 

3. 1.7.2. 2.1  Multiple  Recall  Requests  in  Progress 

*  The  recall  software  will  be  modified  to  allow  multiple 

recall  requests  to  be  processed  under  a  terminal  identifier  of  TTO:  or 
the  CSP  console  device.  Currently,  a  limit  is  specified  in  TRMCOM 
allowing  only  one  recall  request  to  be  initiated  from  the  console.  By 
eliminating  this  limitation  in  TRMCOM  and  the  checks  in  RCLCON, 

I  multiple  recall  requests  can  be  entered  manually  from  the  CSP  console 

and  automatically  from  SVCCON. 

3. 1.7. 2.2. 2  Actions  Taken  Upon  Recall  Failure 

Each  recall  command  line,  generated  automatically  by 
SVCCON,  will  be  printed  on  the  CSP  console  along  with  a  suitable 
indication  that  the  command  line  was  produced  internally.  The  recall 
software  will  then  search  the  CSP  message  file  for  the  requested 
message.  Upon  completion  of  the  search,  RCLCON  will  indicate  the 
number  of  messages  recalled.  If  no  messages  were  found  the  operator  or 
shift  supervisor  will  have  to  intervene  in  the  recall/retransmission 
process.  The  service  message  that  initiated  the  recall  search  will  be 
on  the  SVC  queue.  It  will  be  the  TCC's  responsibility  to  use  the 
service  message  to  initiate  alternative  recall  commands  from  other 
references  to  the  requested  messages  and  perform  any  other  necessary 
follow  up  procedures  in  handling  the  request  for  retransmission. 

3. 1.7. 2. 2. 3  Release  Authority  for  Selected  Output  Queues 

In  order  to  monitor  the  auto-recall  data  flow  and  ensure 
that  the  recall  requests  are  handled  correctly,  selective  local 
(non-AUTODIN  and  non-NSA)  output  queues  may  be  configured  with  a  "no 
auto-recall  allowed"  bit  set.  This  means  that  once  a  requested  message 
I  has  been  recalled  and  re-addressed,  RCLCON  will  identify  the  intended 

output  queue  and  will  test  the  queue  configuration  to  see  if  the  "no 
auto-recall  allowed"  bit  is  set.  If  the  bit  is  set,  the  message  will 
be  marked  in  the  PAD  as  release  authority  required.  Then,  once  the 
message  is  reintroduced,  it  will  eventually  be  placed  on  the  SVC  queue 


I 
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to  be  manually  released  to  the  proper  output  queue  for  retransmission. 
If  the  bit  is  not  set,  the  re-introduced  message  will  be  handled 
normally  by  the  CSP  system  and  will  not  come  up  for  release  authority. 

3. 1.7. 2. 2. 4  Ensuring  AUTODII  Release  Authority 

After  the  recalled  message  has  been  re-addressed  with  the 
new  routing  indicator,  RCLCON  will  search  the  CSP  routing  indicator 
common  area  for  a  match  with  the  message's  TO  RI.  If  no  match  is 
found,  an  AUTODIN  or  NSA  destination  is  assumed.  RCLCON  will  set  the 
release  authority  bit  in  the  PAD  of  the  message  so  that  when  the 
reintroduced  message  is  processed  by  the  Format  Check  software  it  will 
be  queued  for  release  authority  before  being  transmitted  to  it's 
non-local  destination.  This  RCLCON  logic  will  be  performed  whenever  a 
routing  indicator  is  specified  as  the  last  parameter  in  the  recall 
command  line  parsed  by  RCLMCR,  since  this  parameter  will  primarily  be 
used  by  the  auto-recall  software. 

3. 1.7. 3  Diaeusaion 

The  analysis  concluded  that  an  automated  message  recall 
feature  could  be  added  to  CSP,  requiring  a  fairly  simple  and 
straightforward  modification  of  a  few  software  modules.  Potential 
benefits  to  be  derived  would  include  a  decrease  in  operator  workload  at 
the  TCC  and  increased  speed  of  delivery  for  recalled  messages. 

The  analysis  and  conclusions  were  presented  to  the  CSP  User's 
Conference  during  August,  1983,  but  the  consensus  of  the  group  was  that 
implementation  of  this  feature  should  be  deferred  for  the  present.  It 
was  felt  that  this  capability  would  impose  a  processing  burden  on  CSP 
and  derive  very  little  benefit.  Most  Mode  II  tributaries  would 
continue  to  use  the  telephone  to  communicate  recall  requests  and 
therefore  this  capability  would  not  be  used  much.  This  capability 
however  should  be  tabled  until  TCATA  has  had  an  opportunity  to  comment 
on  it,  since  they  were  not  represented  at  the  users  conference. 
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3.1.8  Direct  AUTODII  Interface  (SOW  4.1.3) 


3 .1.8.1  Objective 

Analyze  the  capability  to  interface  directly  to  the  AUTODIN 
Switching  Center  independently  of  special  AUTODIN  interface  devices, 
such  as  TLC,  AID,  or  INTEQ. 

3. 1.8. 2  Accomplishments 

The  analysis  of  this  capability  was  begun  by  examining  DCA 
Circular  370-D175-1,  DCS  AUTODIN  Interface  and  Control  Criteria.  This 
publication  describes  the  operational  characteristics  to  be  used 
between  switching  centers  and  between  centers  and  their  tributaries. 
Also  considered  wa6  the  design  of  the  AUTODIN  interface  module  being 
used  in  the  Realtime  AUTODIN  Interface  and  Distribution  System  (RAIDS). 
Because  several  areas  of  CSP  design  were  patterned  after  RAIDS  and 
because  the  RAIDS  AUTODIN  interface  has  many  structural  similarities  to 
a  CSP  gateway,  it  was  determined  that  using  this  software  would  reduce 
the  design  effort  considerably. 

This  capability  was  first  brought  to  the  users  attention  at  the  CSP 
Users  Conference  in  February,  1983  and  again  at  the  August,  1983 
Conference.  In  both  instances  the  consensus  among  the  users  was  to 
suspend  this  effort  and  not  to  implement  this  capability. 

3. 1.8.3  Discussion 

There  were  several  objections  raised  by  both  current  and 
potential  CSP  users  regarding  the  implementation  of  this  capability. 
They  include  hardware,  operational,  and  security  reasons. 

Most  of  the  current  users  felt  that  eliminating  the  TLC-100  or 
Inteq  AUTODIN  interface  device  would  not  benefit  them  to  a  great  extent 
since  they  already  have  the  units  and  most  likely  would  not  eliminate 
them  if  the  capability  were  developed  within  CSP.  Although  some 
problems  were  noted  with  the  hardware,  it  was  not  viewed  as  being 
excessive. 

Operationally,  it  was  felt  that  eliminating  the  interface  device 

would  remove  some  of  the  indicators  and  status  information  which  is 

currently  supplied  by  these  devices.  For  example,  the  indicator  lights 

on  the  device  currently  show  several  conditions:  synchronization,  no 
reply  from  AUTODIN,  Wait  Before  Transmitting,  character  frame, 
end-of-text  transmitted  and  received,  and  message  cancelled.  This 
information  would  have  to  be  supplied  by  other  means  to  effectively 

monitor  the  AUTODIN  circuits. 


Another  major  operational  consideration  raised  was  the  use  of  the 
alternate  mode  on  the  ADT0D1N  interface  device.  This  capability  allows 
the  user  to  continue  operating  even  when  the  processor  is  down  by 
connecting  a  Mod  40  teletype  to  the  device  and  initiating  the  alternate 
mode  logon  sequence.  This  capability  would  be  eliminated  entirely  if  a 
software  solution  was  implemented. 

The  security  accreditation  and  DCA  certification  of  the  CSP  is 
based  on  the  existence  of  an  AUTODIN  interface  device  which  in  itself 
is  certified.  Any  variation  of  this  would  cause  a  full  reaccreditation 
and  recertification  of  CSP  as  an  AUTODIN  tributary.  This  would  require 
a  full  Category  I  and  Category  III  certification  by  DCA.  Whereas  the 
Cat  III  certification  is  routinely  performed  on  CSP,  the  Cat  I  test  is 
a  very  difficult  thing  to  satisfy.  DCA  examines  all  new  interfaces 
based  on  very  rigid  criteria  which  were  not  in  effect  at  the  time  of 
the  original  Cat  I  certification  of  the  TLC. 

For  these  reasons,  it  was  decided  that  this  capability  should  be 
placed  on  hold  and  not  to  expend  the  resources  to  complete  this  task. 


3.1.9  CSP  Site  Support  (SOW  4.1.4) 
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Task  activities  under  CSP  Site  Support  are  comprised  of  six 
categories  of  user  assistance:  pre-installation  support;  installation 
configuration;  installation,  test  and  checkout;  user  familiarization 
and  training;  enhancements/updates  distribution;  and  installation 
configuration  management.  All  supported  sites  saw  activity  in  one  or 
more  of  these  categories  during  the  year  of  this  report. 

3. 1.9.1  Pre-Installation  Support/Site  Surveys 

Before  a  CSP  software  installation  is  begun,  Informatics 
reviews  the  detailed  hardware  configuration,  the  operational 
requirement,  and  the  program  milestones.  This  is  accomplished  through 
a  site  survey,  including  discussions  of  operational  concepts  and 
requirements  with  site  users  representing  functions  such  as 
requirements,  operations  and  communications.  New  site  managers  are 
provided  pre-installation  procedures  to  ensure  timely  and  successful 
installation  of  selected  software  modules.  During  the  report  period, 
site  surveys  were  conducted  at  FSTC,  DIA,  NAVINTCOM,  NPIC  and  NOSC. 

3. 1.9. 2  Installation  Configuration 

Once  the  site  surveys  were  accomplished  and  the  necessary 
information  gathered,  the  CSP  configuration  to  be  installed  was 
tailored  at  the  central  support  facility  to  meet  the  requirements  of 
the  specific  site.  During  the  year,  configuration  of  software  modules 
included  those  for  FTD,  LANTCOM,  PDSC,  DSAFE,  REDCOM,  OSAREUR ,  TFC , 
MAC,  and  SAC.  For  two  of  these  sites,  USAREUR  and  MAC,  the  central 
support  facility  first  configured  CSP  Release  2.2  C2,  and  later  Release 

2.3  to  meet  project  installations. 

3. 1.9. 3  Installation,  Test  and  Checkout 

The  process  of  completing  a  transfer  of  the  configured  CSP 
software  system  into  an  initial  operational  status  at  the  user  site 
involves  a  multi-faceted  effort  consisting  of  the  software  installation 
itself,  system  generation,  system  checkout,  and  test  support.  From  the 
contractor  support  side,  installation  is  a  two-person  effort.  One  of 
the  individuals  concentrates  on  building  the  system  and  configuring  all 
the  site  unique  parameters,  while  the  second  assists  the  user  in 
preparing  the  user-maintained  tables  such  as  routing,  dissemination, 
user  IDs  and  security  tables.  Since  maintenance  of  these  functions  is 
a  user  responsibility,  it  is  important  that  the  user  be  thoroughly 
capable  of  performing  the  necessary  actions.  Training  of  user 
personnel  proceeds  immediately  upon  completion  of  the  installation,  one 
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person  devoting  his  time  to  this  task  while  the  other  performs  a 
thorough  system  test  in  accordance  with  the  CSP  Installation,  Test  and 
Site  Acceptance  Plan. 

For  installations  of  new  Releases  or  updates  into  an  existing  CSP 
site,  many  of  the  same  procedures  are  followed;  however,  since  the  user 
is  already  familiar  with  CSP  operational  procedures,  the  full  formal 
test  and  acceptance  procedures  are  unnecessary.  During  the  period  of 
this  report,  installations  were  completed  at  USAREUR,  MAC,  FTD,  ADCOM, 
PDSC,  USAFE,  REDCOM,  SAC,  and  LANTCOM. 

3. 1.9. 4  User  Familiarisation  and  Training 

As  indicated  above,  user  personnel  must  be  prepared  to  accept 
responsibility  for  certain  CSP  maintenance  functions  once  installation 
has  been  completed.  For  a  new  installation,  even  experienced  operators 
completely  familiar  with  communications  procedures,  will  not  be 
immediately  conversant  with  the  conventions  associated  with  CSP 
operations.  For  these  reasons,  a  new  installation  is  accompanied  by  a 
thorough  familiarization  with  the  maintenance  of  routing, 
dissemination.  User  ID,  and  Security  Tables  as  well  as  hands-on 
training  with  the  equipment.  The  familiarization  process  is  generally 
less  extensive  when  the  installation  consists  merely  of  an  update  of 
the  site  software  or  replacement  with  a  new  Release.  However,  central 
support  personnel  conduct  training  to  the  degree  required  to  verify 
that  the  user  will  encounter  no  significant  problems  in  proceeding  with 
the  new  operational  configuration.  This  training  was  conducted  in 
conjunction  with  installations/updates  at  USAREUR,  MAC,  FTD,  SAC, 
ADCOM,  PDSC,  USAFE,  REDCOM,  and  LAMTCOM. 

3. 1.9. 5  Enhancements/Updates  Distribution 

As  enhancements  are  developed  they  are  distributed  from  the 
Central  Support  Facility  to  the  user  sites.  The  distribution  includes 
the  update  tape  along  with  all  necessary  support  documentation.  In 
case  of  a  more  substantial  update,  requiring  implementation  procedures 
beyond  local  site  capability,  both  delivery  and  installation  are 
accomplished  by  central  contractor  personnel.  During  the  report 
period,  CSP  update  tape  V23A  was  sent  to  those  sites  with  Release 
version  2.3  installed;  and  a  distribution  of  update  V23B  was  in 
progress  at  the  close  of  the  report  period. 

3.1.9. 6  Installation  Configuration  Management 

As  software  installations  are  completed  at  the  individual 
sites,  all  installation  information  was  turned  over  to  the 
configuration  management  group  for  use  in  completing  the  site  hardware 
and  software  inventory.  The  responsibilities  of  the  Configuration 


Manager  and  a  discussion  of  Che  Configuration  Management  Program  are 
contained  in  section  3.1.15  below.  Installation  Configuration  updates 
were  completed  during  the  report  year  at  ADCOM,  REDCOM,  FTD,  LANTCOM, 
PD SC ,  USAREUR,  USAFE,  TFC ,  MAC,  and  SAC. 
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3.1.10  Training  (SOW  4.1.5) 

3.1.10.1  Objective 


Training  for  users,  in  addition  to  the  familiarization  training 
associated  with  installation  of  an  update  or  enhancement,  may  be 
conducted  as  necessary  either  at  the  Central  Support  Facility  or  at  the 
user  location.  This  training  generally  consists  of  somewhat  more 
formal  instruction,  usually  tailored  to  the  needs  of  a  particular  user. 
This  training  therefore  encompasses  the  full  spectrum  from  full 
classroom  training  of  programmers  to  hands-on  training  of  operators  at 
either  an  operational  site  or  the  Central  Support  Facility. 

3.1.10.2  Accomplishments 

Training  at  varying  levels  was  provided  for  FTD,  USAREUR, 
ADCOM,  FDSC,  LANTCOM,  OSAFE,  REDCOM,  TFC,  SAC,  and  MAC.  This  training 
primarily  covered  the  new  capabilities  associated  with  installation  of 
Release  2.3.  FARM  and  PLA  training  was  provided  to  key  maintenance 
personnel  to  allow  them  to  create  and  maintain  the  respective  data 
bases. 


New  training  materials  have  been  prepared  and  published.  They 
consisted  of  a  slide  presentation  that  explains  the  basic  philosophy 
and  operation  of  CSP,  and  a  set  of  exercise  scenarios  to  provide 
hands-on  training  in  handling  various  normal  and  unexpected  situations. 
These  scenarios  were  provided  in  the  form  of  a  student  guide  and  an 
associated  training  official  guide.  Also  included  is  an  operator 
reference  guide  which  can  be  placed  at  the  operators  console  position 
for  ready  reference. 

3.1.10.3  Discussion 

Training  is  considered  an  ongoing  effort  and  cannot  be 
defined  in  terms  of  a  start  and  a  completion  of  activities.  As  a  CSP 
system  is  installed  for  the  first  time  at  a  given  location,  full  CSP 
training  is  provided  to  the  communications  operators,  computer 
operators,  systems  management  personnel  and  maintenance  programmers. 
Thereafter,  as  personnel  rotate  it  is  the  responsibility  of  the  site  to 
train  their  new  operators.  The  training  materials  provided  under  this 
work  effort  are  designed  to  be  an  aid  to  the  site  in  preparing  their 
own  training  program.  It  can  be  tailored  as  desired  to  incorporate  the 
site-unique  features  and  local  operating  procedures  required  by  each 
site. 


3.1.11  CSP  Software  Inventory  (80V  4.1.6) 

3.1.11.1  Objective 


A  software  inventory  shall  be  maintained  of  all  CSP  software 
modules  which  can  be  configured  into  a  CSP  based  system.  This 

inventory  shall  include  the  support  history  of  each  module  and  shall  be 
the  baseline  to  which  all  future  system  additions  or  modifications  will 
be  applied.  A  site-unique  software  inventory  shall  be  maintained  for 
each  site  which  will  identify  that  subset  of  CSP  baseline  software 
configured  for  a  given  installation,  as  well  as  the  tailored  modules 
that  were  developed  to  satisfy  the  site-unique  automation  requirements. 

3.1.11.2  Accomplishments 

During  the  report  period  CSP  Release  2.3  was  completed  and 

installed  at  several  sites  ,  replacing  Version  2.2C2,  and  Update  Tape 

V23A  was  provided  to  all  sites  with  Version  2.3.  The  CSP  software 
inventory  was  consequently  revised  to  reflect  these  changes  to  the 

system  baseline  and  the  site  baselines,  as  appropriate.  A  similar 
revision  will  occur  to  the  site  software  inventories  as  Update  Tape 
V23B  is  delivered  and  installed. 

3.1.11.3  Discussion 

As  is  evident  from  the  number  of  updates,  enhancements,  and 
entirely  new  features  described  elsewhere  in  this  report,  CSP  is  a 
dynamic  program,  continually  being  revised  to  acconmodate  community 
requirements  as  identified  by  APIS.  The  periodic  revisions  to  meet  the 
requirements  of  the  user  community  necessitate  reestablishment  of  the 
CSP  baseline  on  a  fairly  regular  basis.  In  addition  to  the  common 
baseline  configuration,  individual  sites  have  peculiar  requirements 
which  must  be  tailored  to  meet  their  unique  needs.  When  added  to  the 
CSP  baseline,  the  site  unique  software  results  in  a  baseline  which 
differs  somewhat  from  that  of  any  other  site. 

Key  to  effective  management  of  the  CSP  Program  is  a  method  of 
controlling  the  software  modules  which  comprise  both  the  baseline  CSP 
system  and  those  of  the  individual  sites.  To  insure  the  required 
degree  of  management  control,  a  software  inventory  is  maintained  of  all 
software  modules  which  can  be  configured  into  a  CSP  based  system.  This 
inventory  includes  the  support  history  of  each  module.  An  additional 
inventory  is  maintained  of  the  site-unique  software  for  each  site. 
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3.1.12  AFIS  Support  (SOW  4.1.7) 

3.1.12.1  Objective 


As  part  of  the  overall  CSP  management  program.  Informatics 
assists  AFIS  by  maintaining  a  central  repository  for  system 
enhancements.  This  process  includes  assistance  in  the  evaluation  of 
site-specific  requirements  and  the  development  of  the  applications  to 
meet  the  user  need.  After  the  enhancement  has  been  completed  and 
reviewed  by  AFIS  for  the  Air  Force,  it  is  made  part  of  the  baseline, 
and  the  software  is  made  available  to  other  sites. 

3.1.12.2  Accomplishment a 

Because  AFIS/IND  has  not  had  its  own  computer  installation 
nor  the  facilities  to  maintain  the  CSP  baseline  and  distribute  software 
to  the  user  sites,  the  CSP  baseline  has  been  maintained  by  Informatics, 
under  contract,  at  their  Bellevue,  Nebraska  software  development 
facility.  As  changes  have  been  made  to  the  baseline,  revisions  to  the 
software  modules  were  incorporated  into  an  update  tape  for  distribution 
to  the  user  sites.  This  process  originally  required  that  the  site 
system  be  reassembled  and  re-taskbuilt  after  each  change,  since 
revisions  were  distributed  in  source  form  only.  Once  the  system  had 
developed  sufficiently  to  permit  installation  in  object  form,  however, 
most  changes  were  also  distributed  as  object,  rather  than  source,  code. 
Source  code  continues  to  be  provided  but  only  as  necessary  for  specific 
modules,  such  as  those  which  reconfigure  system  tables  and  site-unique 
parameters. 


3.1.12.3  Discussion 

In  addition  to  assisting  AFIS  in  maintaining  the  central 
repository  and  processing  system  enhancements.  Informatics  provides 
additional  assistance  by  processing  the  system  problem  reports  (CPRs) 
generated  as  a  result  of  field  experience.  When  the  CPR  cannot  be 
resolved  directly  from  the  experience  base  of  the  central  support 
programmers,  the  field  problem  is  researched  thoroughly,  attempting  to 
recreate  the  site  situation  when  possible,  and  a  reply  provided  to  the 
affected  site.  Problem  Reports  are  discussed  more  fully  under  section 
3.1.17,  Software  Maintenance  Support. 


3.1.13  Software  Engineering  (SOS  4.1.8) 

3.1.13.1  Objective 

Computer  software  delivered  in  the  course  of  this  contract 
shall  be  implemented  in  accordance  with  RADC  Software  Development 
Specification  CP  0787796100E,  dated  30  May  1979. 

3.1.13.2  Accemplishaents 

Several  key  modules  within  CSP  have  been  written  in  a  Program 
Design  Language  (PDL)  to  ease  the  future  migration  to  a  high  order 
language.  This  PDL  forces  the  software  to  be  in  a  very  structured 
format  and  therefore  the  transition  to  any  high  order  language  will 
become  a  much  easier  task. 

3.1.13.3  Discussion 

Since  all  coding  for  CSP  in  the  first  phase  of  the  CSP 
Enhancements  Contract  has  been  in  MACRO-11,  the  choice  of  a  high  order 
language  does  not  enter  into  the  software  engineering  constraints  on 
CSP.  This  will,  however,  become  more  important  as  the  CSP  system 
progresses  to  a  point  where  it  will  be  rewritten  in  a  high  order 
language.  This  point  will  be  addressed  in  the  next  phase  of  the 
contract  in  the  High  Order  Language  Analysis  Technical  Report. 


3.1.14  Software  Quality  Assurance  (SOW  4.1.9) 
3.1.14.1  Objective 


The  Software  Quality  Assurance  task  was  implemented  to 
monitor  and  control  the  quality  of  the  software  being  developed,  assure 
that  software  delivered  under  this  contract  complied  with  the 
requirements  of  this  contract,  and  to  guarantee  that  the  CSP  software 
was  developed,  tested  and  maintained  in  an  effective  and  efficient 
manner . 

3.1.14.2  Accomplishments 

Early  in  the  contract  period  the  Software  Quality  Assurance 
Program  Plan  was  published.  Procedures  were  established  for  work 
tasking  and  authorization,  testing,  corrective  action,  library 
controls,  documentation  preparation,  software  reviews,  and  software 
development  techniques  and  methodologies.  Throughout  the  contract 
period  the  enforcement  of  these  standards  has  contributed  immeasurably 
to  the  development  of  consistently  high  quality,  and  thouroughly  tested 
CSP  software. 

As  part  of  the  Software  Quality  Assurance  effort.  Informatics  has 
developed  a  procedure  to  help  monitor  the  CSP  development  effort.  A 
programmer  first  completes  a  check-out  sheet  and  identifies  the  module 
name,  the  current  version,  the  programmers  account,  the  date  and  the 
reason  for  checking  it  out.  The  programmer  makes  the  necessary  changes 
to  the  module  in  his  own  account  and  performs  testing  and  evaluation  of 
the  module.  When  this  is  completed,  the  programmer  notifies  the 
configuration  manager  who  gives  this  check-out  form  to  the  project 
manager/quality  assurance  manager.  This  module  then  undergoes 
extensive  retesting  and  validation  and  if  ready,  is  baselined  by  the 
project  manager.  Since  it  is  possible  for  a  given  module  to  be  checked 
out  by  more  than  one  person,  this  procedure  helps  to  ensure  that 
changes  being  made  by  two  people  to  the  same  module  will  not  adversely 
affect  the  final  result.  This  entire  procedure  provides  an  effective 
audit  trail  for  identifying  changes  to  the  baseline  and  aids  the 
configuration  management  effort.  1 


3.1.14.2.1  Plan  Preparation 

The  Software  Quality  Assurance  Plan  was  prepared  according 
to  the  guidelines  provided  in  MIL-STD-1521 ,  Technical  Review  and  Audits 
and  DOD  Standard  7935. 1-S,  DOD  Automated  Data  Systems  Documentation 
Standards.  Particular  attention  was  given  to  a  practical 


implementation  of  a  plan  that  could  be  implemented  in  a  manner  that 
would  assure  that  the  software  would  be  of  the  highest  possible 
quality. 

3.1.14.2.2  SQA  Activities 

Although  the  SQA  philosophy  is  constantly  present,  it  was 
particularly  evident  in  the  implementation  of  the  new  CSP  Release  2.3 
baseline.  This  involved  major  changes  to  the  software  to  incorporate 
new  features  and  enhancements.  Thorough  testing  and  certification  was 
promoted  by  the  SQA  implementation  guidelines  (CSP  Software  Quality 
Assurance  Program  TR83-431 10-02,  March,  1983).  Baseline  testing  and 
verification  procedures  followed  the  guidelines  established  in  the  CSP 
Installation,  Test  and  Site  Acceptance  Plan,  which  describes  in  detail 
the  site  preparation,  system  generation,  site  operational  tables, 
training  and  security  accreditation.  The  Software  Quality  Assurance 
Program  activities  were  a  portion  of  every  phase  of  CSP  software 
development,  testing,  implementation,  training,  accreditation,  and  site 
acceptance. 
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3.1.15  Configuration  Management  (SOW  4.1.10) 

3.1.15.1  Objectives 


Configuration  management  is  the  application  of  systematic, 
technical  and  administrative  procedures  to  identify  and  document  the 
functional  and  physical  characteristics  of  the  CSP  baseline  modules  as 
well  as  the  site  unique  software  for  each  CSP  installation. 
Configuration  management  is  used  to  ensure  adherence  to  well  defined 
procedures  for  implementing  additions  or  modifications  to  the  CSP 
standard  system  and  provides  a  mechanism  for  recording  and  reporting 
system  status  and  changes. 

3.1.15.2  Accomplishments 

Configuration  management  records  were  updated  to  reflect  the 
installation  of  CSP  release  2.3  at  ADCOM,  REDCOM,  MAC,  USAFE,  USAREUR, 
PD SC,  TCATA,  TFC  and  SAC. 

CDRL  A009,  Configuration  Management  Plan  was  completed  and  published 
in  March  1983. 

Configuration  Control  Board  (CCB)  meetings  were  conducted  during 
the  semi  annual  CSP  Users  Conferences  in  February  and  September  1983. 
These  meetings  reviewed  all  proposed  suggest  ions/ enhancements  tfcit  had 
been  submitted  by  all  sites  in  the  a  form  of  a  CPR. 

3.1.15.2.1  Software  Inventory 

An  accurate  record  of  CSP  software  was  maintained  during 
this  contract  period  with  the  aid  of  an  automated  Configuration 
Management  System  (CMS)  developed  at  Informatics.  With  the  use  of  this 
in-house  tool,  all  CSP  baseline  software  was  identified  and  recorded. 

3.1.15.2.2  Software  Modifications  Control 

As  CSP  software  updates  were  incorporated  into  the  CSP, 
either  as  modifications  to  baseline  or  site-unique,  they  were  logged 
into  the  CMS  using  a  unique  coding  system.  Using  this  coding  system,  it 
was  possible  not  only  to  track  the  updated  versions  per  baseline  but  to 
identify  and  record  the  site  unique  software  modifications  as  well. 

3.1.15.2.3  Software  Modification  Distribution 

As  new  or  updated  CSP  modules  were  released  and 
distributed,  the  configuration  management  system  played  an  essential 
part  in  maintaining  records  of  the  releases.  Using  a  site  subsystem  in 
the  automated  system,  a  record  of  the  most  current  CSP  release  per 
site,  was  maintained. 


3.1.15.2.4  Site  Configuration  Support 

The  CMS  supported  each  site  configuration  by  maintaining  a 
site  inventory.  This  included  for  each  site  the  current  CSF  release, 
the  date  of  installation  and  any  site  unique  software. 

3.1.15.3  Discussion 


Informatics  has  developed,  as  an  in-house  tool,  an  automated 
configuration  management  system  to  aid  in  the  identification  and 
maintenance  of  all  CSP  software.  This  tool  has  been  a  valuable  asset 
by  providing  an  accurate  record  of  changes  within  the  CSP  for  the  past 
two  years.  It  reflects  the  software  inventory,  software  modifications, 
problem  logging,  CSP  documentation  and  site  inventory  and  has  proved  to 
be  an  instrumental  aid  in  ensuring  the  integrity  of  the  CSP. 


3.1.16  Computer  Program*  (SOW  4.1.12) 

3.1.16.1  Objective 

All  computer  programs  assembled  or  developed  under  this 
contract  were  delivered  in  the  form  of  source  and  object  code  on 
magnetic  tape,  and  accompanied  by  source  listings.  Assembly  language 
was  used.  The  goal  of  this  task  was  to  ensure  that  the  most  current 
version  of  all  CSP  software  is  delivered  to  AFIS/IND  for  distribution 
within  the  prescribed  procedures. 

3.1.16.2  Accomplishments 

Since  AFIS/IND  did  not  have  a  computer  facility  or  the 
capability  of  maintaining  the  baseline  and  distributing  the  CSP 
software  to  the  user  sites,  this  baseline  has  been  maintained  by 
Informatics  at  their  Bellevue,  Nebraska  development  facility.  As 
modifications  were  made  to  any  CSP  software  module,  they  were 
thoroughly  tested  before  incorporation  into  the  baseline.  Distribution 
was  made  to  the  user  sites  via  an  update  tape  containing  the  changes 
into  the  user's  system.  This  tape  was  given  to  AFIS  to  duplicate  and 
send  to  each  of  the  current  CSP  sites.  The  system  is  at  the  point 
where  it  can  be  distributed  in  object  format  for  the  majority  of  the 
modules.  Thus  CSP  is  now  installed  in  object  form  and  all 
modifications  are  also  in  object  module  form  where  appropriate.  The 
only  source  code  supplied  to  the  site  are  those  modules  that  are 
required  to  reconfigure  the  system  tables  and  site  unique  parameters. 

3.1.16.3  Discussion 

As  the  computer  facility  is  completed  at  AFIS/IND  the  CSP 
baseline  software  will  be  transferred  to  that  facility  and  maintained 
there.  This  will  consist  of  all  sources  and  object  modules.  From 
there,  object  module  distribution  will  be  made  as  it  is  currently  done 
at  Bellevue.  Any  modifications  made  to  the  CSP  will  be  thoroughly 
tested  and  the  source  code  will  be  shipped  to  AFIS  to  update  the 
baseline. 
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3.1.17  Software  Maintenance  (SOV  4.1.11) 


! 


3.1.17.1  Objective 

Software  maintenance  included  all  work  providing  for 
centralized  maintenance  support  to  all  CUBIC  sites.  This  support  took 
the  form  of  CSP  problem  identification  and  resolution,  as  well  as  CSP 
enhancements.  Problems  were  identified  by  the  CSP  on-site  personnel 
and  resolved  by  project  personnel  at  the  Bellevue  development  facility. 

3.1.17.2  Accomplishments 

Over  the  first  phase  of  the  CSP  contract,  several  major 
accomplishments  were  made  in  correcting  and  enhancing  the  CSP  system. 
As  mentioned  above,  these  accomplishments  included  problem  resolution, 
as  well  as  CSP  enhancements.  CSP  corrections  were  made  in  three  steps: 
problem  identification,  problem  resolution,  and  problem  response.  Each 
separate  process  was  activated  when  needed.  Each  area  is  discussed 
below.  Enhancements  included  suggestions  from  AFIS/IND,  as  well  as  the 
CSP  on-site  personnel.  General  maintenance  support  was  also  performed 
at  thv.-  Bellevue  development  facility. 

3.1.17.2.1  Problem  Identification 

Problem  identification  was  an  important  aspect  of  software 
modification.  For  the  CUBIC  CSP  contract,  problem  identification  took 
two  forms:  full-time,  on-site  support  or  centralized  off-site  support 
from  the  Bellevue  development  facility. 

Generally,  problem  identification  began  with  recognition  of  a  CSP 
malfunction,  attributable  to  software,  by  operators  or  user  personnel 
at  a  CSP  installation.  AFIS/IND  was  informed  of  this  malfunction  by 
the  issuance  of  a  user  report  from  the  CSP  site  where  the  error 
occurred.  After  AFIS/IND  had  validated  the  problem  report.  Informatics 
was  notified  of  the  problem  and  began  to  diagnose  it.  Any  site 
specific  modifications  which  did  not  require  AFIS/IND  approval  were 
corrected  on-site  and  the  changes  communicated  to  the  Bellevue  office. 

3.1.17.2.2  Problem  Resolution 

Once  the  Bellevue  development  facility  received  the  problem 
report  from  AFIS,  the  process  of  problem  resolution  began.  If 
necessary,  phone  conversations  with  the  appropriate  on-site  personnel 
were  conducted,  in  order  to  clarify  the  nature  of  the  problem.  This 
was  followed  by  an  extensive  analysis  of  the  software  malfunction. 
Many  times  this  analysis  would  indicate  that  an  actual  software  error 
had  not  occurred;  the  malfunction  could  be  traced  to  some  ocher  site 

occurrence . 


If  the  problem  was  determined  to  be  a  software  error,  the  required 
corrective  action  was  determined  and  the  resulting  maintenance  task  was 
sized  and  scheduled.  AFIS/IND  was  then  given  necessary  information  as 
to  the  diagnosis  results  and  scheduled  corrections.  Under  the  terms  of 
the  contract,  this  notification  occurred  within  five  days  of  receipt  of 
the  problem  report. 

3.1.17.2.3  Problem  Response 

Once  AFIS/IND  had  been  informed  of  the  status  of  the 
software  error.  Informatics  kept  them  up  to  date  via  the  monthly  status 
report.  All  software  malfunctions  were  identified  as  either  'open'  or 
'closed'. 

Once  the  changes  were  made  and  successfully  tested  at  the  Bellevue 
facility,  distribution  was  made  to  the  appropriate  installation. 
Depending  on  the  time  demands  on  the  problem,  distribution  was  made 
either  immediately  or  at  a  convenient  time,  such  as  the  shipping  of  a 
site  release  tape. 

3.1.17.2.4  General  Maintenance  Support 

Along  with  problem  identification,  resolution,  and 
response,  general  maintenance  support  occurred  at  the  Bellevue 
development  facility.  This  support  included  implementation  of  new  CSP 
releases;  working  with  on-site  user  and  operator  personnel  to 
investigate  CSP  malfunctions;  and  analyzing,  planning,  designing, 
coding,  testing,  installing,  and  documenting  site  unique  software 
modifications.  All  these  software  modifications  were  designed, 
developed,  tested,  and  implemented  in  accordance  with  CSP  quality 
assurance  and  configuration  management  guidelines.  This  general 
maintenance  support  served  as  an  enhancement  to  CSP  functionality. 

3.1.17.3  Discussion 

For  the  most  part,  software  maintenance  functioned  during  the 
course  of  the  CUBIC  CSP  contract  as  described  above.  ..Standard  CUBIC 
Problem  Reports  (CPRs)  provided  a  method  for  identifying  all  CSP  errors 
on  a  numerical  system,  by  site,  as  well  as  in  sequential  order.  In 
addition  to  identifying  CSP  software  errors  in  a  more  efficient 
fashion,  the  CPR  system  also  provided  for  accurate  record  keeping  of 
all  suggestions/enhancements  for  the  CSP.  These  suggestions  and 
enhancements  were  reviewed  by  AFIS  and  Informatics  and,  if  deemed 
appropriate,  were  acted  upon. 

Also  a  telephone  trouble  call  procedure  was  implemented  to  assist  in 
the  identification  and  resolution  of  problems.  As  a  telephone  call  is 
placed  to  the  maintenance  staff  in  Bellevue  by  site  personnel,  the 
details  of  the  problem  are  recorded  on  a  trouble  call  form.  The  caller 


also  identifies  whether  the  problem  is  routine,  immediate  or  urgent. 
This  will  determine  the  response  time  given  the  problem.  All  urgent 
calls  with  the  CSP  system  down  will  be  put  through  immediately.  All 
others  may  be  put  through  or  the  call  may  be  returned. 
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3.2  On-Sit*  Maintenance  (SOW  4.2) 

On-site  maintenance  of  the  baseline,  enhancements,  and  site  unique 
software  was  provided  as  a  site  option.  This  included  analyzing, 
planning,  designing,  coding,  testing,  installing,  and  documenting  site 
unique  software.  The  option  also  included  providing  familiarization  to 
selected  operators  and  programmer/analysts;  identifying,  analyzing, 
reporting  and/or  resolving  software  problems  or  enhancements;  and 
providing  assistance  to  the  operating  agency  on  the  integration, 
installation  and  implementation  of  new  CSP  hardware/software.  Each 
site  currently  receiving  on-site  support  is  discussed  below.  Appendix 
A  contains  additional  information  on  each  site  where  CSP  is  installed. 

3.2.1  TCATA,  Ft.  Hood,  Texas 

On-site  support  was  initiated  during  the  month  of  June,  1981  at 
TCATA.  Some  minor  hardware  problems  were  identified  and  resolved  with 
the  OJ-389  terminal  and  the  BR1569  multiplexer.  Several  joint 
exercises  were  supported  by  CSP  and  the  on-site  personnel  during  this 
contract  period.  In  March,  1983,  the  Remote  Communications  Processor 
(RCP)  was  deployed  to  Ft  Bragg,  North  Carolina  in  support  of  Gallant 
Knight  '83.  Although  Mode  II  circuit  reliability  problems  were  noted, 
CSP  did  not  have  any  significant  problems.  Following  the  exercise,  the 
RCP  was  reconfigured  and  given  a  temporary  recertification  to  run 
message  generation  software  for  the  VT100  terminals  and  a  plotter.  The 
RCP  was  deployed  to  Korea  in  this  configuration  to  support  a  major 
exercise  there.  Upon  return  from  Korea,  the  RCP  was  again  reconfigured 
to  remove  the  VT100  and  plotter  software  and  move  them  to  a  PDP  11/24 
located  in  the  RCP.  This  configuration  was  used  to  support  the  REDCOM 
exercise  in  Florida. 

3.2.2  MAC,  Scott  AFB,  Illinois 

On-site  support  was  initiated  during  the  month  of  June,  1981  at 
MAC  also.  MAC  is  operating  under  a  unique  hardware  configuration  with 
both  the  CSP  tasks  and  the  message  file  on  a  single  disk.  This  does 
not  require  any  special  software  to  support  this  arrangement;  however, 
the  on-site  support  representative  is  needed  to  keep  the  system 
operational  under  this  configuration.  Any  time  the  system  pack  gets 
corrupted  due  to  hardware  failure,  it  is  necessary  to  cold  start  the 
system  since  the  message  file  is  coresident.  This  arrangement  has  not 
appeared  to  hamper  on-line  operations  except  for  the  frequent 
degradation  of  the  ability  to  recover  messages  on-line  from  the  message 
file  after  a  cold  start.  Several  hardware  problems  and  system 
crashes  were  encountered  during  this  contract  period.  Significant 
problems  were  also  noted  with  the  IAS  spooler  task  and  line  printer 
handler.  CSP  Release  2.3  was  installed  and  does  not  use  the  spooler  for 
printing  message  traffic.  Therefore,  many  of  the  problems  appear  to 
have  been  eliminated.  An  attempt  was  made  to  migrate  to  the  PDP  ll/45s 


at  MAC  to  alleviate  the  problems  associated  with  a  single  processor, 
single  disk  system.  This  attempt  was  unsuccessful,  since  the  ll/45s  are 
old  and  unreliable  and  only  support  128K  words  of  memory.  The  existing 
11/70  was  upgraded  by  another  64K  memory  and  appears  to  be  operating 
fine. 

3.2.3  DSAFB,  Rams t tin  AFB,  Germany 

On-site  support  was  begun  at  USAFE  during  the  month  of  August, 

1981.  A  second  FDP  11/70,  with  new  BR1731  multiplexers  and  disk 
drives,  was  installed  during  this  contract  period.  The  CSP  was 
accredited  to  interface  to  a  GENSER-only  MAXI  at  the  OSAFE  OSC  in 
support  of  an  exercise.  This  was  accomplished  using  back-to-back  TLCs 
since  the  signals  had  to  be  encrypted.  A  problem  of  NATO  formatted 
messages  being  incompatible  with  CSP  was  surfaced  during  the  exercise 
and  was  corrected.  Another  unique  problem  that  was  discovered  relates 
to  releasability  of  messages  to  non-OS  personnel.  In  particular,  TOP 
SECRET  messages  should  be  allowed  to  be  released  to  certain  countries 
based  on  the  routing  indicator  and  SPECAT  designator.  The  solution  is 
currently  being  analyzed  and  a  modification  will  be  made  to  CSP  to 
allow  release  of  these  messages. 

3.2.4  LAMTCOM,  Norfolk,  Virginia 

On-site  support  was  initiated  during  the  month  of  September, 
1981  at  LANTCOM.  They  encountered  a  problem  with  the  dual  disk  handler 
in  performing  a  catchup  function  while  the  system  software  was  on  the 
same  type  disk.  Use  of  this  version  of  the  dual  disk  handler  was 
suspended.  A  solution  was  designed  and  baselined  for  the  problem 
surfaced  at  LANTCOM  regarding  the  handling  of  CRITIC  messages.  This 
solution  bypasses  format  checking  if  a  message  is  identified 

3.2.5  ADCOM,  Colorado  Springs,  Colorado 

On-site  support  was  begun  at  ADCOM  during  the  month  of  January, 

1982.  The  actual  installation  of  the  CSP,  however,  did  not  occur  until 
mid  August  1982,  due  to  facility  construction  delays.  A 
receive  magnetic  tape  capability  was  configured  to  support  two  customers 
at  NORAD/SPACECOM.  Several  problems  were  noted  with  the  TLCs  dropping 
out  of  synch  and  the  attempt  to  bring  up  a  ZICON  line.  Both  of  these 
problems  were  resolved  by  getting  a  new  down-load  module  for  the  BR1731 
multiplexer  from  Bunker-Ramo.  A  DYNATECH  switch  was  installed  to 
overcome  the  problems  they  were  having  with  their  redundant  BR1731 
channels.  A  modification  to  the  FARM  software  was  made  and  incorporated 
into  the  baseline  which  will  allow  routing  to  offices  solely  based  on 
routing  indicator. 
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3.2.6  REDCOM,  MacDill  AFB,  Florida 


On-site  support  was  initiated  at  REDCOM  during  the  month  of 
April,  1982.  The  Mod  40  circuit  to  RDJTF  was  reconfigured  as  a  full 
duplex  channel  through  the  BR1731  multiplexer.  This  necessitated  a  new 
down-load  module  from  Bunker  Ramo.  A  remote  OJ-389  terminal  was  then 
installed  in  the  CENTCOM  area  to  provide  this  support  instead  of  the 
Mod  40.  This  terminal  has  the  same  capabilities  as  the  REDCOM  0J-389s 
but  operationally  only  one  queue  is  used.  A  major  new  capability  is 
being  designed  and  coded  at  REDCOM  to  provide  a  separation  of  traffic 
for  the  two  commands,  USREDCOM  and  USCENTCOM.  This  remote  comm  center 
capability  will  route  to  each  terminal  based  on  RI/OSRI  for  incoming 
traffic,  messages  in  error  and  release  authorization. 

3.2.7  SAC,  Offutt  AFB,  Rebraska 

On-site  support  was  initiated  at  SAC  under  this  contract  during 
the  month  of  April,  1982.  Actual  on-site  support  was  provided  at  SAC 
from  the  time  of  the  original  installation  in  1978,  however,  this 
support  was  provided  under  a  separate  contract  to  SAC.  In  April,  the 
separate  SAC  contract  was  terminated  and  SAC  became  a  formal  CUBIC/CSP 
user.  Because  of  its  proximity  to  the  Informatics  development 
facility,  much  of  the  support  provided  to  SAC  consists  of  implementing 
new  software  and  running  a  thorough  test  and  evaluation  prior  to  actual 
incorporation  into  the  CSP  baseline.  In  this  manner,  SAC  has  been 
designated  the  lead  command  for  all  CSP  developments.  FARM  and  PLA  were 
both  accredited  for  R/Y  use  and  were  placed  online.  A  new  interface  and 
gateway  were  implemented  through  a  DMC-11  to  the  Micro  Programmable 
Controller. 

3.2.8  USAFE  TFC,  Germany 

On-site  support  at  the  TFC  was  begun  in  July,  1983.  During  the 
initial  few  months  of  support,  the  ESD  contractors  were  still  on-site 
and  making  modifications  to  the  Inter  Computer  Communications  (ICC) 
gateway  software.  Therefore,  Informatics'  role  was  one  of  evaluation  of 
the  system  and  implementation  of  the  baseline  software.  Actual  baseline 
software  support  was  provided  during  this  period  but  no  other 
modifications  were  supported.  Upon  successful  accreditation  of  the 
entire  system  at  the  current  release  of  CSP,  full  software  support  will 
be  provided. 


3.3  CDRLs 


The  following  CSP  documents  were  successfully  completed  and 
delivered  during  the  contract  period. 

3.3.1  CSP  Status  Report  (CDRL  ROOD 

The  CSP  Contract  Status  Report  was  issued  monthly  and  identified 
the  status  and  activities  for  all  tasks  in  progress  in  terms  of 
performance,  status  and  work  planned  for  the  next  reporting  period. 
Additional  sections  were  included  that  identified  management  items  of 
concern,  a  management  level  work  summary,  all  CSP  contract  related 
travel  and  changes  in  project  personnel. 

3.3.2  CSP  Overview  (CDRL  A002) 

The  CSP  Overview  provided  an  overview  of  system  objectives  and 
requirements  suitable  for  management  and  general  informational  purposes. 
It  was  prepared  in  accordance  with  Data  Item  Description  No. 
R&D-188-RADC . 

3.3.3  Functional  Description  (CDRL  A003) 

The  Functional  Description  provided  a  description  of  common 
system  capabilities  which  were  used  to  describe  the  system  to  potential 
users,  to  preview  the  system  when  training  user  personnel,  to  serve  as 
a  reference  for  user  personnel  and  to  provide  a  performance  checklist 
after  installation.  Because  this  document  was  used  by  staff  who  did 
not  necessarily  have  computer  system  experience,  it  was  written  using 
language  which  was  as  nontechnical  as  possible.  It  was  prepared  in 
accordance  with  Data  Item  Description  No.  DI-E-30104A. 

3.3.4  System/Subsystem  Specification  (CDRL  A004) 

The  System/SubBystem  Specification  provided  a  detailed 
definition  of  CSP  functions  and  interfaces  with  other  system  and 
subsystems.  It  was  in  accordance  with  Data  Item  Description  No. 
DI-S-30551A. 

3.3.5  Program  Specification  (CDRL  A005) 

The  Program  Specification  is  a  technical  document  used  to  guide 
programmers  in  developing  code.  The  Program  Specification  was  prepared 
in  accordance  with  Data  Item  Description  No.  DI-S-30552A. 


3.3.6  Test  Plan  (CDBL  A006) 


The  Test  Plan  provides  guidance  for  management  and  technical 
efforts  throughout  the  installation,  test  and  training  period  for  each 
installation.  The  Test  Plan  establishes  a  comprehensive  test  plan  so 
that  users  and  security  personnel  can  demonstrate  and  validate  the 
operational  capabilities  of  CSP.  By  defining  and  publishing  a 
benchmark,  against  which  the  system  can  be  made  to  perform,  the  process 
of  DIA/DCA  certification  can  be  made  simpler  and  more  standardized  for 
the  user,  while  at  the  same  time  providing  DIA/DCA  with  a  well  defined 
procedure  and  published,  expected  results.  The  Test  Plan  was  published 
in  accordance  with  Data  Item  Description  No.  DI-T-30703A. 

3.3.7  Computer  Operation  Manual  (CDBL  A007) 

The  CSP  Computer  Operation  Manual  contained  complete  detailed 
information  on  the  system  console  oriented  towards  computer  operators 
who  were  responsible  for  the  overall  performance  of  the  CSP  and 
included  appendices  covering  system  error  messages  and  Bystem  commands. 
The  manual  was  prepared  in  accordance  with  Data  Item  Description  No. 
DI-M-30402A. 

3.3.8  Program  Maintenance  Manual  (CDBL  A008) 

The  CSP  Maintenance  Manual  will  present  detailed  program 
descriptions  for  all  CSP  modules  and  information  on  the  maintenance  of 
these  modules.  It  is  technical  in  nature  and  will  be  developed  for 
personnel  who  were  responsible  for  the  maintenance  of  computer 
programs.  This  document,  together  with  a  program  listing  containing 
programmer  comments,  will  assist  the  maintenance  programmer  in  making 
modifications  to  the  existing  system  programs  as  requirements  change. 
The  Maintenance  Manual  will  be  prepared  in  accordance  with  Data  Item 
Description  No.  DI-M-30402A. 

3.3.9  Configuration  Management  Flan  (CDBL  A009) 

The  CSP  Configuration  Management  Plan  (CMP)  specified  procedures 
for  the  achievement  of  the  CUBIC  CMP  configuration  management  goals  for 
the  subset  of  all  CSP  software  developed,  disseminated  and/or  maintained 
by  Informatics  General  Corporation  under  the  CUBIC  Management  Program. 
The  Configuration  Management  Plan  was  prepared  in  accordance  with  Data 
Item  Description  No.  DI-E-3108. 

3.3.10  Quality  Program  Plan  (CDBL  A010) 

The  Quality  Program  Plan  identifies  requirements  and  procedures 
for  the  software  Quality  Assurance  Program.  It  was  produced  in 
accordance  with  Data  Item  Description  No.  DI-R-30510. 


3.3.11  Teat  Analysis  Report  (CDRL  A011) 


The  Test  Analysis  Report  was  produced  by  the  Informatics  team 
following  accreditation  testing  of  the  CSP  for  new  installations  or  new 
releases  of  CSP  software.  These  reports  consisted  of  a  synopsis  of 
test  activities  including  a  description  of  any  problems  encountered. 
The  Test  Analysis  Reports  were  produced  in  accordance  with  Data  Item 
Description  No.  DI-T-30704A. 

3.3.12  CSP  Operating  System  Upgrade  and  CSP  Hardware  Configuration 
Interim  Technical  Report  (CDRL  A012) 

The  CSP  Operating  System  Upgrade  Interim  Technical  Report 
contained  results  of  an  analysis  to  convert  the  CSP  operating  system  to 
RSX-11M  or  RSX-11M+.  The  hardware  configuration  report  addressed  the 
capability  to  make  certain  software  modifications  related  to  a  scaled 
down  hardware  version  of  the  CSP.  This  technical  report  was  prepared 
in  accordance  with  Data  Item  Description  No.  DI-S-3591A/M. 

3.3.13  Message  Distribution  Clerk,  Multiplexer  Interface,  and  History 
and  Intercept  Capabilities  Interim  Technical  Report  (CDRL  A013) 

Three  reports  were  produced  as  part  of  this  contract 
deliverable.  The  first  consisted  of  a  report  on  the  feasibility  of 
optionally  supporting  the  Message  Distribution  Clerk  functions  via  a 
single  screen  terminal.  The  second  report  addressed  the  capability  to 
optionally  interface  to  all  communications  interfaces  and  peripheral 
devices  independently  of  the  BR1569  or  BR1731  multiplexer.  The  final 
report  was  provided  on  the  capability  of  the  CSP  to  optionally  provide 
history  and  intercept  functions  utilizing  a  disk  as  opposed  to  tape. 
The  Technical  reports  were  prepared  in  accordance  with  Data  Item 
Description  DI-S-3591A/M. 

3.3.14  Ancillary  Control  Procoasor  and  Message  Recall  Interim  Technical 
Report  (A014) 

The  Technical  Report  consisted  of  the  results  of  an  analysis  to 
provide  message  recall  and  retransmission  based  on  communication 
requests  to  the  CSP.  This  report  was  produced  in  accordance  with  Data 
Item  Description  No.  DI-S-3591A/M. 

3.3.15  Direct  AUTODIH  Interface  Interim  Technical  Report  (CDRL  A015) 

The  Technical  Report  for  the  feasibility  of  a  direct  software 
interface  to  an  AUTODIN  Switching  Center  (ASC)  was  to  include  results 
of  an  analysis  effort  projecting  impacts  on  memory  utilization. 
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throughput,  efficiency  and  security  accreditation.  The  report  was  not 
prepared  due  to  the  consensus  of  users  at  the  August  1983  CSP  Users 
Conference  to  place  this  item  on  hold. 

3.3.16  Final  Technical  Report  (CURL  A016) 

This  Final  Technical  Report  (FTR)  for  the  CSP  Support  contract 
summarizes  the  results  of  work  performed  during  the  contract  period. 
This  report  identifies  CSP  capabilities  and  deliverable  products  that 
were  produced. 

3.3.17  Training  Coarse  Outline  (CURL  A017) 

A  Training  Course  Outline  was  produced  which  consists  of  an 
outline  of  training  to  be  provided  to  both  programmers  and  operators. 
It  was  produced  in  accordance  with  Data  Item  Description  No.  DI-H-5060. 

3.3.18  Training  Haterial  (CDRL  A018) 

Training  Material  was  provided  to  both  operators  and 
programmers.  It  included  a  slide  presentation,  operator  positional 
reference  guide,  and  exercise  scenarios  for  the  student  and  training 
official.  The  training  material  was  prepared  in  accordance  with  Data 
Item  Description  No.  DI-H-5061. 

3.3.19  Users  Manual  (CDRL  A019) 

The  CSP  Users  Manual  contains  complete  detailed  information  on 
the  MDC/SVC  terminal  to  successfully  operate  the  CSP.  It  was  oriented 
towards  message  distribution  personnel  who  are  responsible  for  the 
efficient  performance  of  the  CSP  and  includes  appendices  covering 
message  distribution  terminal  error  messages.  The  Users  Manual  was 
prepared  in  accordance  with  Data  Item  Description  No.  DI-M-30401A. 

3.3.20  Interface  Control  Document  (CDRL  A020) 

The  Interface  Control  Document  will  consist  of  a  summary  for 
interface  control  to  the  MAXI.  This  document  will  be  published  during 
the  next  phase  of  the  contract  to  coincide  with  the  completion  of  the 
analysis  of  the  CSP/MAXI  interface  task  in  Option  1.  It  will  be 
completed  in  accordance  with  Data  Item  Description  No.  DI-E-30131. 

3.3.21  Work  Plan  (CDRL  A021) 

The  Work  Plan  consists  of  a  planned  approach  for  the  successful 
completion  of  each  task.  It  provides  the  following  information:  task 
plans,  technical  approach,  task  breakdown  and  schedule  estimate. 


deliverable  products  and  delivery  dates,  resource  estimates,  projected 
travel  and  machine  time  requirements.  The  Work  Plan  was  produced  in 
accordance  with  Data  Item  Description  No.  R&D-58A-RADC. 
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SECTION  4.  Summary  and  Recommendations 

Reviewing  the  accomplishments  of  this  phase  of  the  current 
contract  reveals  that  many  tangible  improvements  have  been  made  to  CSP 
which  brings  more  flexibility  into  the  configuration  and  operation  of 
the  telecommunications  center.  An  alternative  to  magnetic  tapes  is 
now  available  for  any  site  not  wishing  to  operate  with  tapes.  A  fully 
redundant  system  can  be  configured  using  only  disk  media  or  using  both 
disk  and  tapes.  Alternatives  are  also  being  developed  for  the 
BR1569/BR1731  multiplexer.  When  completed,  this  will  offer  a  choice  to 
any  prospective  CSP  user  or  any  current  user  wishing  to  expand 
capabilities.  Significant  advances  were  also  made  in  development  of  a 
single-screen  terminal  capability  as  an  alternative  to  the  large, 
expensive  OJ-389.  This  terminal,  a  Delta-Data  8252T,  will  offer  a 
plug-compatible  alternative  at  about  one-fifth  the  cost  of  the  current 
requirement . 

Another  visible  improvement  has  been  the  modifications  designed  for 
transportability.  The  CSP  software  can  be  installed,  configured  and 
made  test  ready  in  under  half  a  day  and  be  done  in  a  fashion  which 
provides  complete  audit  trail  and  configuration  management  information. 

From  a  functionality  standpoint,  it  can  be  seen  from  the  above  that 
significant  improvements  have  been  made  to  the  CSP.  To  the 
aforementioned  list  could  be  added  numerous  other  improvements  of  a 
lesser  nature,  but  nonetheless  supporting  the  evolution  of  CSP  from  a 
relatively  primitive  communications  processor  to  an  automated  full 
function  communications  system. 

Throughout  this  evolution  the  design  and  implementation  process  has 
included  considerable  thought  toward  anticipation  of  future 
requirements.  For  example,  while  the  PLA  capability  was  not  scheduled 
for  completion  until  late  1982,  the  foundation  for  PLA,  in  terms  of 
data  structure  modifications  and  other  "hooks",  was  laid  as  far  back  as 
1980.  This  has  allowed  integration  with  virtually  no  impact 
anticipated  on  existing  installations  when  upgrading  to  PLA.  Release 
2.3  of  CSP  has  included,  of  course,  PLA,  FARM  and  many  other 
enhancements,  but  it  also  included  "hooks"  for  future  anticipated 
expansion.  Several  changes  have  been  anticipated  and  the  foundations 
laid  for  running  CSP  on  a  smaller  hardware  configuration,  elimination 
of  the  History/Intercept  tape  requirement  and  modifications  to  the  MDC 
terminal  operations. 

CSP  has  been  evolving  along  other  lines  besides  functionality.  The 
original  CSP  for  SAC  was  fairly  restrictive  as  to  the  hardware 
configuration  it  required  for  operation.  For  instance,  usage  of  other 
than  DEC  TU10  tape  drives  for  history  and  intercept  required  software 
changes.  Today,  CSP  is  much  less  restrictive  as  to  hardware 
requirements.  With  consideration  given  to  performance  and  capacity 
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requirements,  CSF  can  be  offered  as  a  system  able  to  run  on  the  entire 
family  of  PDP-11  processors  (except  for  11/23  and  11/24  because  of  IAS 
operating  system  constraints).  CSP  can  use,  as  a  message  file  data 
base,  any  disk  drive  supported  by  the  operating  system  and  the  same 
holds  true  for  mag-tape  devices.  Because  CSP  was  designed  for  device 
independence,  it  can  take  immediate  advantage  of  new  peripheral 
offerings  as  soon  as  they  become  available  with  operating  system 
support . 

With  the  advances  in  hardware/software  technology  projected  to 

proceed  at  their  current  phenomenal  rate,  it  will  not  be  long  before  the 
current  CSP  hardware/software  architecture  will  be  updated  with  respect 
to  available  technology. 

From  a  hardware  standpoint  the  industry  move  is,  and  always  has 
been,  towards  more  processing  power  in  smaller  packages.  Much  more 
emphasis  is  being  placed  on  distributed  processing  techniques  in  an 
effort  to  expand  the  capabilities  of  these  smaller  processors,  as  well 
as  limit  the  reliance  on  a  single  processor  for  all  functions.  The 

other  obvious  use  of  distributed  processing  is  to  get  more  capabilities 
to  more  people. 

Software  is  also  undergoing  a  change  in  terms  of  how  people  view 
its  use.  With  the  current  evolution  of  higher  order  languages  (HOLs), 
the  frequency  of  machine  language  (MACRO-11,  BAL,  etc.)  implementations 
of  computer  programs  will  drop  dramatically  as  more  powerful  and 
flexible  HOLs  become  available.  Machine  language  has  historically  been 
selected  for  use  because  of  its  efficiency  and  ability  to  manipulate 
the  hardware  and  small  units  of  data  (bits,  bytes,  etc).  It  was  also, 
in  many  cases,  the  only  language  available  on  minicomputers  in  the 

early  stages  of  development.  This  is  rapidly  changing,  however,  and 
the  time  is  not  far  off  when  machine  language  will  be  a  tool  used  only 
by  the  hardware  designer  when  building  the  machine  itself.  Consider 

the  DEC  VAX  11/780  which  implements  sophisticated  data  structure 
manipulation  operations  in  its  instruction  set,  or  the  Commercial 
Instruction  Set  (CIS)  option  for  the  PDP-11/24  and  11/44.  Many 
microprocessors  are  commercially  available  that  offer  the  PASCAL,  BASIC 
and  "C"  languages  implemented  in  firmware  which  cannot  be  easily 
programmed  in  machine  language.  A  major  drawback  to  machine  language 
has  been  and,  by  definition,  will  continue  to  be,  cost.  While  it  is 
generally  efficient  in  its  operational  form,  the  cost  to  develop  it 
continues  to  escalate  as  labor  costs  rise.  Machine  language 
programmers  are  hard  to  find  and  good  ones  demand  high  salaries.  The 
efficiency  of  machine  language  is  directly  dependent  upon  programmer 
expertise  while  with  higher  order  languages  a  large  amount  of 
efficiency  can  be  "built  in"  to  the  compiler  and  the  language  itself. 
Another  drawback  to  machine  language  is  dependency.  For  example, 
software  coded  in  PDP  MACRO-11  cannot  be  executed  on  anything  but  a 


PDP-11.  This  is  not  necessarily  true  of  HOLs.  A  program  written  in 
"C",  PASCAL,  or  ADA  will  run  on  a  variety  of  computers  supporting  that 
language. 

Where  does  this  all  fit  with  CSP?  One  can  begin  by  looking  at  the 
user.  Telecommunications  centers  serve  a  vital  but  relatively  minor 
role  in  the  process  of  intelligence  information  gathering  and 
dissemination.  The  message  traffic  itself  is  merely  data  until  it  gets 
into  the  hands  of  the  intended  recipient  where  its  true  value  comes 
into  play.  Many  of  the  processes  taking  place  in  a  communications 
center  require  significant  manpower  allocation  but  represent  minor 
capabilities  for  computer  systems.  As  these  TCC  processes  are 
translated  into  software,  less  effort  need  be  expended  on  moving  data 
and  more  can  be  spent  on  developing  the  tools  for  using  it. 

Most  communication  centers  have  limited  space  that  must  be  shared 
between  people,  communications  equipment,  administrative  offices  etc 
and  finding  room  for  two  PDP-11/70  systems  can  be  a  problem.  It  is, 
therefore,  incumbent  upon  system  designers  to  provide  more  compact  and 
efficient  systems  which  get  the  job  done  but  do  not  have  the  impact  on 
space  of  the  current  larger  systems.  Coupled  with  smaller  size  and 
increased  performance,  is  a  constant  requirement  to  reduce  costs  both 
in  hardware  procurement/operation  and  in  software  development  and 
maintenance. 

Cost  reduction  and  performance  improvement  can  be  accomplished 
through  use  of  newer,  smaller,  more  powerful  equipment  including 
distributed  processing  techniques  and  through  other  techniques  such  as 
software  preparation  in  a  suitable  higher  order  language  such  as  ADA. 
The  result  will  be  a  very  efficient  (in  cost,  space  and  performance) 
system  with  wide  flexibility  and  applicability. 

To  a  certain  extent  CSP  stands  at  a  crossroads  with  respect  to 
future  evolution.  In  its  current  state  CSP  is  a  solid,  well  defined 
system.  If  TCC  requirements  were  never  to  change  and  currently  used 
hardware  continued  to  be  available,  then  CSP  could  continue  to  be  a 
viable  system.  However,  neither  of  the  above  premises  are  true  and 
some  decisions  must  now  be  made  concerning  the  evolutionary  path  to 
take.  No  single  path  represents  a  clear-cut  decision.  On  one  hand 
there  is  strong  support  for  migration  of  CSP  to  smaller  hardware  which 
would  give  the  same  or  slightly  more  capability  than  the  current 
system.  This  makes  sense  from  the  standpoint  that  the  hardware  is 
moving  in  that  direction  and  TCC's  don't  usually  have  physical  space  to 
spare.  On  the  other  hand,  changing  TCC  requirements  such  as 
consolidation  of  DSSCS/GENSER  facilities  as  well  as  overall  expansion 
of  communication  requirements  tends  to  support  the  move  of  CSP  to 
larger,  faster  hardware.  In  its  current  form,  using  current  21(V) 


hardware,  CSP  is  throughput  limited  to  perhaps  6000-8000  messages /day . 
This  is  adequate  for  most  applications  but  clearly  inadequate  for  many 
potential  users. 

It  is,  of  course,  a  well  known  fact  that  DOD  is  pursuing  a  solution 
to  the  current  AUTODIN/Tr ibutary  problem  with  development  of  the 
Inter-Service/Agency  AMPE.  CSP  is  the  interim  standard  AMPE  and,  as 
such,  is  scheduled  to  be  replaced  by  I-S/A  AMPE,  or  is  it?  Even  though 
I-S/A  AMPE  would  automate  TCC's  as  well  as  serve  as  switching  nodes  for 
the  DIN  network,  does  that  eliminate  the  requirement  for  message 
processing  systems  connected  to  I-S/A  AMPE?  Today,  CSP  provides  70%  of 
the  functionality  projected  for  I-S/A  AMPE  and  rough  estimates  for 
I-S/A  AMPE  operation  are  for  the  late  1980's;  CSP  will  have  to  provide 
service  until  then. 

The  work  items  identified  in  the  next  phase  of  this  contract 
represent  some  real  direction  in  this  decision  making  process. 
Conversion  of  CSP  to  a  higher  order  language  is  an  absolute  necessity. 
It  must  be  pursued  with  serious  dedication.  ADA  represents  the 
clear-cut  choice  of  languages.  Lack  of  approved  compilers  is  a 
temporary  problem,  but  it  is  anticipated  that  very  shortly  the  computer 
manufacturers  will  begin  to  make  available  accredited  ADA  compilers 
along  with  the  necessary  development  tools.  The  problem  of  hardware 
dependence  must  be  resolved.  This  will,  in  fact,  be  partially 
alleviated  by  conversion  to  a  HOL  but  more  work  must  be  done  in  order 
to  use  standard,  vendor  supplied  options;  thus  removing  the  reliance  on 
unique  (expensive)  sole  source  equipment. 

For  CSP,  the  past  few  years  of  work  have  seen  the  overall 
organization  and  stabilization  of  the  system  into  a  well  defined 
product.  New  capabilities  were  added  in  a  methodical  and  well  planned 
fashion.  With  respect  to  functionality,  CSP  is  now  mature.  The  work  to 
be  performed  over  the  next  several  years  must  focus  on  evolution 
towards  refinement  of  the  technology  and  expansion  of  applicability  and 
flexibility. 


HQ  SAC,  Offutt  AFB,  Nebraska 


Site  Location 

The  CSP  became  operational  at  HQ  Strategic  Air  Command  (SAC)  in 
September  1978.  The  CSP  was  developed  at  HQ  SAC  as  part  of  the 
Operational  Intelligence  Support  System  (OISS)  of  the  IDH  Improvements 
Project . 

SAC  has  a  world-wide  mission  of  deterring  war  by  being  prepared  to 
conduct  strategic  operations  on  a  global  basis  with  the  objective  of 
destroying  an  enemy's  will  or  capability  to  wage  war. 

CSP  provides  both  DSSCS  and  GENSER  communications  support  for 
transmission  and  reception  of  real-time  AUTODIN  messages  in  support  of 
SAC's  mission.  In  addition,  the  CSP  functions  as  a  front-end  processor 
for  the  Analyst  Support  Processor  (ASP),  which  directly  supports  SAC's 
intelligence  analysts. 

Equipment  Configuration 

The  CSP  at  SAC  is  currently  implemented  on  the  following  hardware 
for  the  primary  system: 

o  CPU  -  One  (1)  PDP-11/70  with  256K  memory 

o  System  console  -  One  (1)  LA120  DECwriter 

o  Disk  drives  -  Three  (3)  BR1538D  (shared) 

One  (1)  RL01 

o  Tape  drives  -  Two  (2)  TE16 

Three  (3)  TU10  (shared) 

o  Multiplexer  -  One  (1)  36-channel  BR1569 

o  Line  printers  -  One  (1)  LP11WA  (shared) 

One  (1)  B600 

One  (1)  TT  Mod-40  ROP  (shared) 

o  AUTODIN  Interface  Device  -  Two  (2)  TLC100  (shared) 

o  Message  Distribution  Console  -  Three  (3)  OJ-389  (shared) 

o  Other  Equipment  -  One  (1)  VT52  terminal 

One  (1)  paper  tape  reader /punch 
One  (1)  CRll  card  reader  (shared) 
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The  backup  system  is  configured  identically  to  the  primary.  Those 
items  listed  as  "shared"  above  are  switchable  between  the  two 
processors.  Additionally,  individual  circuits  terminating  in  the  BR1569 
multiplexer  are  switchable  between  both  processors  by  means  of  BR1568 
switches . 

Software  Configuration 

Figure  A-01  contains  a  site  report  extracted  from  Informatics' 
Configuration  Management  System.  This  report  reflects  the  current 

software  release  level  for  this  site,  the  date  of  software  installation 
and  implementation,  and  a  status  of  pending  releases.  Also  included 

are  any  site  unique  modules  developed  for  this  particular  site. 

CooBunications  Configuration 

The  CSF  is  dual-homed  to  Tinker  and  Gentile  ASCs  for  online 
tributary  operations,  both  DSSCS  and  GENSER.  Backside  tributaries  at 
SAC  include  the  ASF,  Mode  II  send  and  receive  circuits,  and  a  Micro 

Programmable  Controller  (MPC)  to  interface  to  SOLARS. 

A  connectivity  diagram  for  SAC  is  presented  in  Figure  A-02. 

Current  Operations  Statistics 

SAC's  average  traffic  volume  and  CIM  rate  are  as  follows: 

o  Messages  transmitted  -  1569  per  month 

o  Line  blocks  transmitted  -  112,086  per  month 

o  Messages  received  -  56,301  per  month 

o  Line  blocks  received  -  1,421,982  per  month 

o  CIM  Rate  -  .572 

The  CSP  is  able  to  maintain  approximately  37  days  of  online  storage. 
SAC  has  been  able  to  maintain  a  low  CIM  rate  due  to  the  extensive  format 
and  security  checks  performed  by  the  CSP. 

Approximately  752  of  the  incoming  messages  are  derivatively  routed 
to  the  ASP.  Another  5-72  are  derivatively  routed  to  the  SOLARS  system. 
Approximately  52  of  the  incoming  messages  are  derivatively  routed  to 
the  SRC.  The  remainder  of  the  incoming  messages  is  routed  by  the 
FARM  software  or  the  message  distribution  clerk. 


SITE:  SAC  (SAJ 


I  RELEASE:  2.3 

STATUS:  OPERATIONAL  15-APR-83 

DATE  OF  INSTALLATION:  15-APR-B3 

I  REMARKS:  NONE 

******************************************************************************** 
■  UNIQUE  MODULES: 


******************************************************************************** 


OUTSTANDING  PROBLEM  REPORT: 

CM  #:  SA-82-0005 

STATUS:  ENHANCEMENT 
DESCRIPTION: 

SUGGEST  ALL  SYSTEM  HISTORY  STATS  AND  LML'S  BE  GENERATED  IN  AUTODIN 
MESSAGE  FORMAT  HOURLY  f WITH  BO  MINUTE’S  DATA)  AND  RECORD  ON  BOTH  DISK 
AND  HISTORY  TAPE.  ADDITIONALLY,  ONE  COMPLETE  LML  SHOULD  BE  GENERATED  AT 
RADAY  AND  RECORDED  ON  TAPE  AND  DISK  —  AS  NELL  AS  BEING  PRINTED  ON  THE 
SERVICE  PRINTER  tSVP) .  THE  MESSAGE  COULD  BE  IN  EITHER  DSSCS  OR  GENSER 
FORMAT,  ACCORDING  TO  LOCAL  REQUIREMENTS  AND  CONTENT. 

THIS  ENHANCEMENT  IS  SCHEDULED  FOR  BASELINING. 

CM  #:  SA-82-2001 

STATUS:  UNDER  ANALYSIS 
DESCRIPTION: 

WHILE  ATTEMPTING  TO  SERVICE  A  BACKSIDED  MODE  II  TERMINAL  USING  MESSAGE 
RECALL  ON  A  MESSAGE  THAT  HAD  BEEN  RECENTLY  PROCESSED  THRU  THE  SYSTEM, 

OLD  MESSAGES  WERE  ERRONEOUSLY  RECOVERED. 

ECO:  1 -DEC-63 

CM  #:  SA-83-2002 

STATUS:  ENHANCEMENT 
DESCRIPTION: 

WHEN  USING  'LOGGEN',  THE  INFORMATION  IS  PRNTED  AS  IT  IS  READ  ROM  TAPE. 
THIS  PRODUCES  A  PRINTOUT  THAT  IS  DIFFICULT  TO  READ  AND  IS  NOT  IN  ORDER  BY 
MESSAGE.  ALSO,  OPERATORS  ARE  UNABLE  TO  SELECT  A  PORTION  OF  A  TAPE  TO  LOG. 

THIS  ENHANCEMENT  IS  UNDERGOING  TESTING  BEFORE  BASELINING.  IT  IS 
INTENDED  AS  AN  OFF-LINE  JOB.  ONCE  ON-LINE,  GIVE  RECOMMENDATIONS. 
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CM  #:  SA-83-2003 

STATUS:  ENHANCEMENT 
DESCRIPTION: 

SUGGESTION  TO  PROVIDE  FARM  WITH  THE  OPTIONTO  ALLOW  MANUAL  PROCESSING  OF 
CERTAIN  CODEWORDS  AND  CLASSIFICATIONS. 

THIS  SHOULD  BE  A  CURRENT  CAPABILITY.  CURRENTLY  UNDERGOING  INFORMATICS 
EVALUATION. 

CM  #:  SA-83-2004 

STATUS:  UNDER  ANALYSIS 
DESCRIPTION : 

AFTER  A  GENSER  MSG  CONTAINING  MORE  THAN  ONE  PAGE  IS  PROCESSED  BY  PLA,  PLA 
DOES  NOT  ADD  THE  SPECIAL  HANDLING  DESIGNATORS  OF  THE  MSG  ON  PAGE  2  OR  ANY 
SUCCEEDING  PAGES.  EXAMPLE:  MESSAGE  CLASSIFICATION,  SECRET  NOFORN 
WNTNTEL.  PAGE  2  IS  PROCESSED  AS  SECRET  VICE  SECRET  NOFORN 
WNTNTEL. 
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Figure  A-02  SAC  Connectivity  Diagram 


The  station  reliability  for  SAC  including  both  hardware  and  software 
outages  is  approximately  99.64%. 

Future  Operations 

There  are  plans  to  replace  the  interface  to  the  ASP  with  a  DDCMP 
protocol  gateway  utilizing  the  BR1569  multiplexer.  This  gateway  will 
also  implement  a  full-duplex  capability,  allowing  ASP  to  transmit  DD 
Form  173  messages  through  CSP  to  AUTODIN.  Messages  will  be  given 
release  authorization  at  the  CSP  prior  to  introduction  into  AUTODIN. 

Site  Personnel 

There  are  no  CUBIC/CSP  on-site  representatives  per  se  at  SAC.  The 
close  proximity  of  the  Bellevue  facility  to  SAC  makes  it  possible  for 
the  personnel  at  the  contractor's  facility  to  assist  in  system  trouble 
shooting.  This  effort  is  conducted  largely  by  Mr.  Barry  King,  PRC.  Mr 
King  works  closely  with  the  communications  and  data  processing  staffs 
of  SAC.  His  primary  point  of  contact  is  1st  Aerospace  Communications 
Group . 


A-6 


HQ  MAC,  Scott  AFB,  Illinois 


Site  Location 

CSP  was  installed  at  HQ  Military  Airlift  Command  (MAC)  in  June 
1979.  This  was  the  second  installation  of  CSP  after  SAC  successfully 
demonstrated  the  ability  of  the  CSP  to  the  military  intelligence 
community. 

MAC  has  a  world-wide  mission  of  providing  airlift,  logistic,  supply 
and  transport  support  to  all  DOD  elements.  A  secondary  mission 
consists  of  supporting  Air  Force  Communications  Command,  Air  Rescue  and 
Recovery  Service  and  Air  Weather  Service  components. 

CSP  provides  both  DSSCS  and  GENSER  communications  support  for 
transmission  and  reception  of  real-time  AUTODIN  messages  in  support  of 
MAC's  mission.  In  addition,  the  CSP  functions  as  a  front-end  processor 
for  the  MAXI  system,  which  directly  supports  MAC's  intelligence 
analysts . 

Equipment  Configuration 

The  CSP  at  MAC  is  currently  implemented  on  the  following  hardware 
for  the  primary  system: 

o  CPU  -  One  (1)  PDP  11/70  with  256K  memory 

o  System  Console  -  One  (1)  LA36  DECwriter 

o  Disk  Drives  -  One  (1)  BR1538D 

o  Tape  Drives  -  Three  (3)  TUI 6 

o  Multiplexer  -  One  (1)  32  channel  BR1569 

o  Line  Printers  -  Two  (2)  80  character  line  printers 

o  AUTODIN  Interface  Device  -  One  (1)  TLC100 

o  Message  Distribution  Console  -  Two  (2)  OJ-389 

o  Other  equipment  -  One  (1)  VT52  terminal 

One  (1)  Paper  tape  reader /punch 

There  is  currently  no  backup  processor  to  be  used  in  the  event  the 
PDP  11/70  or  one  of  its  peripherals  is  down.  If  the  down-time  is 
excessive,  a  PDP  11/70  used  to  support  MAXI  can  be  recabled  to  run  CSP. 
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Software  Configuration 

Figure  A-03  contains  a  site  report  extracted  from  Informatics 
Configuration  Management  System.  This  report  reflects  the  current 
software  release  level  for  this  site,  the  date  of  software  installation 
and  implementation  and  a  status  of  pending  releases.  Also  included  are 
any  site-unique  modules  developed  for  this  particular  site. 

Communications  Configuration 

The  CSP  is  homed  to  ASC  Gentile  for  online  operations,  both  DSSCS 
and  GENSER.  The  only  backside  tributary  at  MAC  is  the  MAXI  system. 
There  are  no  other  local  tributaries  or  communications  lines  configured 
at  this  time. 

A  connectivity  diagram  for  MAC  is  presented  in  Figure  A-04. 

Current  Operations  Statistics 

MAC's  average  traffic  volume  and  CIM  rate  are  as  follows: 
o  Messages  transmitted  -  1,225  per  month 
o  Messages  received  -  25,225  per  month" 
o  CIM  rate  -  .33% 

The  traffic  volume  has  been  steadily  increasing  at  the  rate  of 
10-15%  per  year,  while  the  CIM  rate  has  been  declining  dramatically. 
This  decrease  in  CIMs  is  largely  due  to  the  increased  format  checking 
and  stricter  security  checks  placed  on  each  message  by  the  CSP. 

With  MAC's  current  message  volume  and  single  disk  configuration, 
the  online  message  storage  capacity  is  approximately  37  days. 

Virtually  all  of  the  incoming  messages  ar  reviewed  and  routed  by 
the  MDC  operator.  However,  approximately  90%  of  these  messages  are 
routed  to  the  MAXI  system. 

The  station  reliability  rate  for  MAC  has  averaged  97.4%.  This 
reflects  total  system  reliability  and  includes  both  hardware  and 
software  downtimes  as  well  as  PMIs. 

Future  Operations 

One  change  anticipated  is  to  obtain  a  second  TLC100  and  a  link  to 
Tinker  ASC  and  become  dual-homed  to  provide  redundancy  and  faster 
service. 


SITE:  MAC  (MA] 


RELEASE:  2.3A 

STATUS:  OPERATIONAL  23-SEP-83 

DATE  OF  INSTALLATION :  16-SEP-83 

REMARKS:  NONE 

******************************************************************************** 

UNIQUE  MODULES: 

NONE 


******************************************************************************** 
OUTSTANDING  PROBLEM  REPORT: 

CM  #:  MA-B3-2009 

STATUS:  PROBLEM  ON  HOLD 
DESCRIPTION: 

WHEN  THE  MDC/SVC  OPERATOR  IS  ROUTING  TRAFFIC,  THE  LEFT  SCREEN  DISPLAYS 
'QUEUE  EMPTY'.  THE  QUEUE  MESSAGE  COUNTER  INDICATES  THAT  THERE  IS  STILL 
TRAFFIC  IN  THE  QUEUE.  ATTEMPTS  AT  REVIEWING  THE  REMAINING  MESSAGES  ON 
THE  QUEUE  BY  GOING  FROM  THE  AFFECTED  QUEUE  TO  ANOTHER  AND  BACK  WILL  NOT 
CORRECT  THE  DIFICULTY.  ON  OCCASION,  IF  THE  M3  C/SVC  OPERATOR  WAITS  UNTIL 
THE  QUEUE  BUILDS  BACK  UP  (B-10  MSGS],  ALL  TRAFFIC  CAN  BE  REVIEWED  AND 
ROUTED. 

NO  ECO,  CANNOT  DUPLICATE  PROBLEM. 

CM  #:  MA-83-201 0 

STATUS:  UNDER  ANALYSIS 
DESCRIPTION: 

AFTER  RECEIPT  OF  A  BAD  MESSAGE,  WE  WOULD  BE  NOTIFIED  BY  THE  ASG  THAT  THEY 
WERE  RECEIVING  'STOPS'  FROM  US,  THUS  INTERRUPTING  THE  TRAFFIC  FLOW.  WHEN 
THE  'MASTER  CLEAR'  WAS  PRESSED  ON  THE  TLC,  WE  WOULD  FIND  ONLY  A  PARTIAL 
MESSAGE  HAD  BEEN  RECEIVED  AND  ATTEMPTS  TO  CAPTURE  THE  MESSAGE  IN  THE  DATA 
SCOPE  WERE  UNSUCCESSFUL.  WE  WERE  INFORMED  BY  THE  ASC  THAT  THE  MESSAGE 
CONTAINED  AN  'EM'  CHARACTER  (SHORT  BLOCK  CHARACTER)  WHICH  THE  ASC  IS  ABLE  T 
TRANSMIT  BUT  OUR  SYSTEM  CANNOT  ACCEPT. 

ECO:  NOT  ESTABLISHED 


Figure  A-03  MAC  Configuration  Status 


Site  Personnel 

The  current  CUBIC/CSP  on-site  representative  at  MAC  is  Mr.  David 
Wittenberg,  Informatics.  He  has  just  recently  replaced  Mr.  Charles 
Ramsey,  Informatics  who  relocated  to  the  Bellevue  central  development 
staff. 


Mr.  Ramsey  has  been  instrumental  in  the  high  rate  of  success  that 
CSP  has  achieved  at  MAC.  He  has  performed  problem  analysis  and 
resolution  in  a  timely  manner  and  has  responded  around-the-clock  to 
online  system  problems.  He  has  also  converted  the  system  to  run  on  the 
PDP-11/45  on  a  test  basis  which  confirmed  that  operational 
implementation  on  that  processor  is  not  feasible. 

His  day-to-day  operations  require  him  to  interact  with  several 
intelligence  divisions  as  well  as  data  automation  and  communications 
center  personnel. 


TCATA,  Fort  Hood,  Texas 


Site  Location 

CSP  was  first  installed  in  November,  1979,  at  the  TRADOC  Combined 
Arms  Test  Activity  (TCATA),  Fort  Hood,  Texas  on  a  PDP-11/45.  During 
September-October ,  1981,  the  CSP  software  was  moved  to  the  home  station 
PDP-11/70.  In  early  November,  1981,  TCATA  was  re-accredited  by  DCA, 
DIA  and  DA.  In  April,  1982  ,  TCATA  installed  CSP  in  the  Remote 
Communications  Package  (RCP),  which  was  designed  by  our  on-site 
consultant,  Russell  Goad,  prior  to  his  release  from  active  duty.  In 
September  1983,  TCATA  was  reaccredited  to  allow  "GENSER  only"  remote 
communications  lines 

TCATA's  CSP  primary  mission  is  to  provide  a  communications 
interface  with  user  units  during  J.C.S.,  REDCOM  and  other  units' 
exercises.  TCATA's  CSP  also  has  a  mission  in  testing  the  Joint 
Tactical  Fusion  Test  Bed  (JTFTB)  located  at  both  Fort  Hood  and  Hurlbert 
Field,  Florida. 

Equipment  Configuration 

The  local  CSP  at  TCATA  has  the  following  hardware  configuration: 
o  CPU  -  One  (1)  PDP-11/ 70  with  2MB  memory 
o  System  Console  -  One  (1)  LA36  DECwriter 
o  Disk  Drives  -  Two  (2)  BR1538D 

o  Tape  Drives  -  Two  (2)  Kennedy  dual  density  drives 
(equivalent  to  TE16s) 

o  Multiplexer  -  One  (1)  32  channel  BR1569 

o  Line  Printers  -  One  (1)  Houston  Instrument  electrostatic 

o  AUTODIN  Interface  Device  -  One  (1)  TLC100 

o  Message  Distribution  Console  -  One  (1)  OJ-389 

Other  equipment  -  One  (1)  VT100  terminal 

One  (1)  DV11  multiplexer 


o 


The  Remote  Communications  Package  (RCP)  CSP  is  configured  slightly 
differently: 

o  CPU  -  One  (1)  PDP-11/70  with  1  MB  memory 
o  System  Console  -  One  (1)  LA36  DECwriter 
o  Disk  Drives  -  Two  (2)  BR1538D 

o  Tape  Drives  -  Two  (2)  Kennedy  dual  density  drives 
(equivalent  to  TEl6s) 

o  Multiplexer  -  Two  (2)  16  channel  BR1569 

o  Line  Printers  -  One  (1)  LP11Y 

o  AUTODIN  Interface  Device  -  One  (1)  TLC100 

o  Message  Distribution  Console  -  One  (1)  OJ-389 

o  Other  Equipment  -  One  (1)  VT100  terminal 

One  (1)  DV11  multiplexer 

Software  Configuration 

Figure  A-05  contains  a  site  report  extracted  from  Informatics 
Configuration  Management  System.  This  report  reflects  the  current 
software  release  level  for  this  site,  the  date  of  software  installation 
and  implementation  and  a  status  of  pending  releases.  Also  included  are 
any  site-unique  modules  developed  for  this  particular  site. 

Communications  Configuration 

The  connectivity  of  the  two  CSPs  at  TCATA  varies  depending  on  the 
exercise  being  supported.  Generally,  however,  there  is  a  link  to  one 
ASC  and  anywhere  from  one  to  eight  MOD-40  teletypes  configured  as  Mode 
II  devices.  Also,  if  the  exercise  dictates,  there  could  be  a  satellite 
CSP-to-CSP  link  activated  via  the  satellite  communications  gateway. 

The  backside  computer  interface  at  the  local  CSP  consists  of  a 
receive  link  from  the  PDP-11/70  configured  as  a  Tactical  Simulator 
(TACSIM)  Output  Message  Control  and  Timer  (TOMCAT).  During  exercises 
the  TACSIM  processor,  a  VAX  11/780,  generates  messages  through  the 
TOMCAT  which  releases  them  to  CSP  on  a  timed,  controlled  basis.  CSP 
then  forwards  them  to  their  destination. 
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SITE:  TCATA  (TT) 


RELEASE:  2.3A 

STATUS:  OPERATIONAL  16-SEP-B3 

DATE  OF  INSTALLATION :  16-SEP-83 

REMARKS:  INSTAL.  AND  OPERATIONAL  DATES  WERE  FOR  THE  MAIN  VAN. 

THE  RCP  WAS  INSTALLED  AND  OPERATIONAL  ON  23-MAY-83 

******************************************************************************** 
UNIQUE  MODULES: 

NONE 

******************************************************************************** 
OUTSTANDING  PROBLEM  REPORT: 

NONE 


Figure  A-05  TCATA  Configuration  Status 


The  local  lines  consist  of  the  MOD-40  teletypes  mentioned  above 
which  can  be  operated  either  locally  or  remotely.  An  additional 
backside  tributary  off  the  RCP  is  a  PDP  11/24  configured  to  support 
multiple  VT100  message  generation  terminals  and  a  plotter. 

A  connectivity  diagram  for  TCATA  is  presented  in  Figure  A-06. 

Current  Operations  Statistics 

Since  TCATA  is  not  an  operational  site,  there  is  not  a  constant 
traffic  load.  However,  during  the  exercise  periods,  the  TCATA  CSP 
handles  approximately  1800  to  2000  messages  per  day.  If  this  volume 
were  sustained  for  an  extended  period  this  equates  to  54,000  to  60,000 
messages  per  month,  or  almost  double  the  average  volume  for  most  CSP 
sites.  CIM  rates  are  not  calculated  during  exercise  periods,  so  none 
are  available. 

The  hardware  and  software  reliability  has  been  excellent  at  TCATA. 
During  the  two  and  one-half  years  that  CSP  has  been  used  at  TCATA, 
there  has  never  been  a  time  that  TCATA  has  not  been  able  to  support  its 
users  due  to  software  or  hardware  downtimes.  The  only  system  outages 
have  been  caused  by  communications  line  outages. 

Given  the  high  message  volume  and  the  small  amount  of  disk  storage 
allocated  for  the  message  file,  the  current  configuration  allows  for 
approximately  50  days  online  storage. 

Approximately  99%  or  virtually  all  of  the  messages  received  are 
automatically  or  derivatively  routed  by  the  CSP.  This  requires  very 
little  operator  intervention. 

Future  Operations 

An  analysis  is  underway  to  replace  the  PDP-11/70  in  the  RCP  with  a 
daisy  chain  of  PDP-ll/44s  and  ll/24s.  As  the  RCP  is  deployed,  more 
information  will  be  gathered  on  the  evolution  of  the  CSP  in  the 
tactical  environment. 

Site  Personnel 

At  the  present  time  the  on-site  representative  at  TCATA  is  Ms. 
Elizabeth  Crenshaw,  Informatics;  however,  she  is  scheduled  for 
reassignment  and  will  be  replaced  in  November  1983  by  Mr.  Robert 
Richards . 

The  on-site  personnel  have  made  several  significant 
accomplishments.  From  the  time  CSP  was  first  installed  on  the  TCATA 
PDP-11/45  system  in  November,  1979,  and  deployed  for  its  first  major 
successful  exercise  to  Europe,  January  1980,  Informatics  trained 
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TCATA's  operators  and  assisted  TCATA  m  passing  its  first  AUTODIN 
accreditation  test.  During  the  fall  of  1980,  Informatics  was  given  the 
task  of  writing  a  gateway  to  interface  with  the  TCATA  TOMCAT,  a 
replacement  for  SSB.  In  the  fall  of  1981,  Informatics  was  again  tasked 
to  write  a  site  unique  gateway,  SCMCON.  This  gateway  allowed  CSP-to- 
CSP  communications  over  a  Satellite  link.  Informatics  also  assisted  in 
integrating  the  CSP  software  onto  the  same  computer  system  as  the 
TOMCAT  resides.  In  November  of  1981,  the  present  system  successfully 
passed  a  Category  III  AUTODIN  accreditation  test. 

During  day-to-day  operations  the  Informatics  personnel  interface 
with  the  user  organization  through  the  Systems  and  Computer  Operations 
branch  of  the  Battlefield  Automation  Test  Directorate,  TCATA.  They 
work  very  closely  with  several  branches  of  the  Special  Projects  and 
Simulation  Division  as  well  as  contractors  from  Eaton  Corporation  and 


USAFE,  Rams te in  AB,  Germany 


Site  Location 

CSP  was  installed  at  HQ  United  States  Air  Force  Europe  (USAFE), 
Ramstein  AB,  Germany  in  August,  1981.  It  is  located  in  the  USAFE 
Combat  Operations  and  Intelligence  Center  (COIC)  and  supports  the 
intelligence  analysts  by  providing  a  communications  path  to  AUTODIN  for 
transmission  and  reception  of  AUTODIN  messages. 

The  primary  function  of  CSP  is  to  be  the  front-end  processor  for 
the  MAXI  system  at  USAFE  and  to  support  various  intelligence 
communications  circuits.  A  secondary  role  is  the  automation  of  the 
AFSSO  TCC  at  USAFE. 

Equipment  Configuration 

The  USAFE  CSP  is  configured  on  the  following  hardware: 

o  CPU  -  One  (1)  PDP-11/70  with  256K  memory 

o  System  Console  -  One  (1)  LA36  DECwriter 

o  Disk  Drives  -  Four  (4)  BR1538C 

Two  (2)  RK05 

o  Tape  Drives  -  Three  (3)  TE16 
o  Multiplexer  -  One  (1)  BR1569 
o  Line  printers  -  One  (1)  LP05 
o  AUTODIN  Interface  Device  -  Two  (2)  TLC100 
o  Mr -.sage  Distribution  Console  -  Three  (3)  OJ-389 
o  Other  Equipment  -  One  (1)  VT100  terminal 

An  additional  PDP  11/70  configured  identically  serves  as  a  backup. 
Software  Configuration 

Figure  A-07  contains  a  site  report  extracted  from  Informatics 
Configuration  Management  System.  This  report  reflects  the  current 
software  release  level  for  this  site,  the  date  of  software  installation 
and  implementation  and  a  status  of  pending  releases.  Also  included  are 
any  site-unique  modules  developed  for  this  particular  site. 
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SITE:  USAFE  COIC  (CO) 


RELEASE:  2.3A 

STATUS:  OPERATIONAL  15-AUG-83 

DATE  OF  INSTALLATION:  15-AUG-B3 

REMARKS:  NONE 

******************************************************************************** 

UNIQUE  MODULES: 

NONE 


******************************************************************************** 


OUTSTANDING  PROBLEM  REPORT: 

CM  #:  CO-82-0002 

STATUS:  ENHANCEMENT 
DESCRIPTION: 

SUGGESTION  TO  ALLOW  A  SUBSET  OF  »€SSAGES  TO  BE  READ  OFF  OF  THE 
INTERCEPT  TAPE  BY  ORIGINAL  QUEUE  ASSIGNMENT. 

THIS  ENHANCEMENT  IS  UNDERGOING  TESTING  AT  THE  BELLEVUE  FACILITY. 

CM  #:  CO-82-2020 

STATUS:  UNDER  ANALYSIS 
DESCRIPTION: 

WHEN  A  MESSAGE  IS  PREPARED  WITH  A  TRC  CODE  OF  ’TTBB'  ORR  'TTXX'  AND  ALSO 
INCLUDES  THE  SPECAT  OVERRIDES  /FFFFF  OR  /LLLLL ,  THE  CSP  IGNORES  THE 
OVERRIDES  AND  PREVENTS  TRANSMISSION  OF  MESSAGE. 

ESTIMATED  COMPLETION  DATE:  1 -NOV-83 

CM  #:  CO-83-2026 

STATUS:  UNDER  ANALYSIS 
DESCRIPTION: 

SUGGESTION  TO  AUTOMATICALLY  SWITCH  TO  A  SECONDARY  PATH  WHEN  THE  DIN 
PATH  IS  DOWN. 

ESTIMATED  COMPLETION  DATE:  NOT  ESTABLISHED. 

CM  #:  CO-83-2027 

STATUS:  ENHANCEMENT 
DESCRIPTION: 

THE  NUMBER  OF  MESSAGES  WRITTEN  TO  AN  INTERCEPT  TAPE  IS  PROVIDED  ONLY  AFTER 
THE  TAPE  HAVE  BEEN  CLOSED.  THIS  SUGGESTION  IS  TO  PROVIDE  THE  INFORMATION 
DYNAMICALLY  WHILE  THE  TAPE  IS  OPEN  AND  BEING  WRITTEN  TO. 

ESTIMATED  COMPLETION  DATE:  1-DEC-B3 
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CM  #:  CO-83-2028 

STATUS:  ENHANCEMENT 
DESCRIPTION: 

SUGGESTION  TO  ALLOW  1600  BPI  AS  WELL  AS  800  BPI  SUPPORT  BY  MTPCON  TO 
MAINTAIN  COMPATABILITY  WITH  THE  NEW  HOST  HARDWARE  CONFIGURATION. 

ESTIMATED  COMPLETION  DATE:  1 -NOV-83 

CM  #:  CO-83-2032 

STATUS:  PROBLEM  ON  HOLD 
DESCRIPTION: 

FREQUENTLY  WHEN  ONE  OF  OUR  BACKSIDE  TRIBUTARIES  IS  DOWN  FOR  MAINTENANCE, 

WE  MUST  ALTROUTE  ALL  TRAFFIC  TO  AN  INTERCEPT  TAPE.  WE  WOULD  LIKE  THE 
ADDITIONAL  CAPABILITY  TO  ALTROUTE  FLASH  AND  I  MEDIATE  PREC  TRAFFIC  TO  THE 
PRINTER  FOR  IMMEDIATE  DELIVERY.  CURRENTLY,  WE  MUST  TAKE  INFO  CONCERNING 
FLASH  TRAFFIC  FROM  THE  SVP,  RECALL  THE  MSG,  THEN  DO  A  MANUAL  DISTRIBUTION 
OF  THE  MSG  TO  THE  M)P  PRINTER  IN  ORDER  TO  GET  THE  CLASS  STAMPING  ON  THE 
PRINTOUT.  THERE  IS  NO  WAY  TO  TRAP  IMMEDIATE  TRAFFIC. 

EXAMPLE  OF  THE  NEED:  MCR>  ALR  MXI  TO  INT/PRE=P,L 

MCR>  ALR  MXI  TO  MDP/PRE=I,H 

WITHOUT  THIS  CAPABILITY,  AN  ERROR  MSG  IS  GENERATED  STATING  QUE  ALREADY  ALT. 

CM  #:  CO-83-2033 

STATUS:  PROBLEM  ON  HOLD 
DESCRIPTION: 

TRAFFIC  ONLY  COMES  UP  ON  THE  SVC  QUEUE  FOR  RELEASE  AUTHORIZATION  IF  IT  IS 
DESTINED  FOR  AN  AUTODIN  CIRCUIT.  SOMETIMES,  WE  NEED  THE  CAPABILITY  TO 
MONITOR  ALL  TRAFFIC  COMING  FROM  ON  OF  OUR  BACKSIDE  PROCESSORS  TO  THE  OTHER. 
ALSO,  WE  NEED  TO  REVIEW  TRAFFIC  COMING  FROM  A  TAPE  THAT  HAS  BEEN  READ  IN. 

IF  IT  IS  DESTINED  FOR  A  MODE  II  TRIBITARY.  RELEASE  AUTHORIZATION  FOR  LINES 
OTHER  THAN  DIN  WOULD  ALLOW  US  TO  MONITOR  TRAFFIC  FOR  ANY  LINE  ON  AN  AS 
NEEDED  BASIS. 

CM  #:  CO-83-2034 

STATUS:  PROBLEM  ON  HOLD 
DESCRIPTION : 

WHEN  MESSAGE  TRAFFIC  IS  PRINTED  AND  HAND  DELIVERED  TO  A  CUSTOMER,  AN  LML 
MUST  BE  TAKEN  TO  COUNT  THE  NUMBER  OF  MSGS  DELIVERED.  ERRORS  MAY  BE  MADE 
IN  COUNTING  AND  THIS  PROCESS  MAY  TAKE  QUITE  SOME  TIME  IF  THE  LIST  IS  LONG. 
THERE  ARE  OFTEN  SEVERAL  PAGES  OF  THE  LML  LIST  AND  IF  AN  ACCURATE  COUNT 
WERE  PRINTED  ON  THE  DEC  WRITER,  THIS  TROUBLE  COULD  BE  AVOIDED. 
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Communications  Configuration 

The  CSP  at  USAFE  is  dual-homed  to  AUTODIN  via  Pirmasens  and 
Croughton  ASCs.  There  are  two  backside  processors  configured  at  USAFE. 
There  is  a  direct  link  to  the  MAXI  system  for  analyst  support  as  well 
as  a  link  to  the  COIC  host  processor.  There  are  currently  no  remote 
communications  lines  configured  at  this  site. 

A  connectivity  diagram  for  USAFE  is  presented  in  Figure  A-08. 

Current  Operations  Statistics 

USAFE' s  average  traffic  volume  and  CIM  rate  are  as  follows: 
o  Messages  transmitted  -  400  per  month 

o  Messages  received  -  33,000  per  month 

o  CIM  rate  -  not  reported 

With  USAFE's  current  traffic  volume  and  message  file  size,  the 
average  on-line  message  storage  capacity  is  approximately  30  days. 
Virtually  all  of  the  incoming  traffic  is  routed  automatically  via 
derivative  routing  indicator  to  the  MAXI  system. 

The  average  reliability  of  the  CSP  software  at  USAFE  is  99.72. 
This  figure  only  includes  outages  attributed  to  software. 

Future  Operation 

A  MAXI  system,  which  has  been  connected  from  the  OSC  as  a 
GENSER-only  backside  tributary,  will  be  reconnected  to  the  OSC  CSP  in 
February,  1984. 

Site  Personnel 

The  CSP  on-site  representative  at  USAFE  is  Mr.  Raymond  Murphy, 
PRC.  His  daily  operations  require  direct  interface  with  the  HQ  USAFE 
intelligence  and  communications  staffs. 


LABTCOM,  Norfolk,  Virginia 


Site  Location 

CSP  was  installed  at  CINCLANTFLT,  Norfolk,  Virginia  in  October, 
1981  and  is  being  operated  by  U.S.  Navy  data  processing  personnel. 

CSP's  primary  mission  is  to  provide  continuous  message  handling 
support  for  CXNCLANTFLT's  Consolidated  Intelligence  Communication 
Center  (CICC).  In  addition  to  processing  messages  destined  for 
CINCLANFLT,  the  CICC  guards  for  all  major  and  most  subordinate  commands 
within  the  immediate  area.  Numerous  ships  and  embarked  staffs  require 
message  support  depending  upon  ship  movements. 

Equipment  Configuration 

The  CSP  at  LANTCOM  is  currently  implemented  on  the  following 
hardware  for  the  primary  system: 

o  CPU  -  One  (1)  PDP-11/ 70  with  320K  memory 

o  System  Console  -  One  (1)  LA36  DECwriter 

o  Disk  drives  -  Two  (2)  BR1538C  (shared) 

Three  (3)  BR1538D  (shared) 

o  Tape  drives  -  Two  (2)  TE16 

o  Multiplexer  -  One  (1)  BR1369  (shared) 

One  (1)  SMC200 

One  (1)  T-16 

o  Line  printers  -  Two  (2)  MOD-40  printers  (shared) 

One  (1)  LP11RA  (shared) 

o  ADTODIN  Interface  Device  -  Two  (2)  Inteq  1A-5100  (shared) 

o  Message  Distribution  Console  -  Three  (3)  0J-389  (shared) 

o  Other  Equipment  -  One  (1)  VT100  terminal 

One  (1)  CompuScan  COMET  OCR  (shared) 

One  (1)  AN/FGT-7  paper  tape  reader 
(shared) 

Two  (2)  AN/FGR-10  paper  tape  punch 
(shared) 

Two  (2)  MOD-40  remote  printers  (shared) 


The  backup  system  is  configured  almost  identically  to  the  primary. 
Those  items  listed  as  "shared"  above  are  svitchable  between  the  two 
processors.  Otherwise,  the  backup  system  has  one  PDP-11/70  with  384K 
memory,  one  LA36,  and  two  TE16  tape  drives.  This  processor  also  has 
two  RK05  disk  drives. 

Software  Configuration 

Figure  A-09  contains  a  site  report  extracted  from  Informatics 
Configuration  Management  System.  This  report  reflects  the  current 
software  release  level  for  this  site,  the  date  of  software  installation 
and  implementation  and  a  status  of  pending  releases.  Also  included  are 
any  site-unique  modules  developed  for  this  particular  site. 

Communications  Configuration 

The  LANTCOM  CSP  is  dual-homed  with  links  to  Andrews  and  Ft.  Detrick 
ASCs.  There  are  two  ZICON  circuits,  one  transmit/ rece ive  and  one 
receive  only.  Other  remote  communications  lines  consist  of  two  MOD-40 
printers  located  at  LEC  and  FOSIC. 

The  backside  computer  interface  at  LANTCOM  is  configured  as  an  MSS 
line  which  terminates  in  the  CAMHS  PDP-11/70  processor.  This  link  is 
transmit  only. 

A  connectivity  diagram  for  LANTCOM  is  presented  in  Figure  A-10. 
Current  Operations  Statistics 

LANTCOM's  average  traffic  volume  and  CIM  rate  are  as  follows: 
o  Messages  transmitted  -  2,475  per  month 
o  Messages  received  -  45,000  per  month 
o  Line  blocks  transmitted  -  52,700  per  month 

o  Line  blocks  received  -  1,100,000  per  month 

o  CIM  rate  -  .81% 

Even  with  the  high  volume  processed  by  LANTCOM,  the  CSP  is  able  to 
maintain  approximately  35  days  of  online  storage.  A  low  CIM  rate  has 
been  maintained  as  a  result  of  the  extensive  format  and  security  checks 
performed  by  CSP. 


SITE:  CINCLANT  J-2  (LA) 


RELEASE:  2.2C2 

STATUS:  OPERATIONAL  01 -AUG-83 

DATE  OF  INSTALLATION:  01-AUG-B3 

REMARKS:  AWAITING  PATCH  TAPE  FOR  2.3B  TLCCON  FIXES  BEFORE  2.3  IS  PLACED 
ON  LINE. 

******************************************************************************** 
UNIQUE  MODULES: 

NONE 


******************************************************************************** 


OUTSTANDING  PROBLEM  REPORT: 

CM  #:  LA-82-0005 

STATUS:  ENHANCEMENT 
DESCRIPTION: 

INTERFACE  OSIS  BASELINE  TO  PROVIOE  LOCAL  ACCOUNTABILITY  AND  OPTIMIZE 
ON-LINE  DELIVERY  OF  SI/SCI  USAGES.  CSP  HAS  THE  CAPABILITY  TO  UTILIZE 
THE  SSR  GATEWAY  AS  AN  ADDITIONAL  SEND-RECEIVE  BACKSIDE.  THIS  WOULD  ENHANCE 
CURRENT  MEANS  OF  TRANSMITTING  MESSAGES  TO  OSIS. 

AWAITING  REQUIREMENTS  DEFINITION  AND  IMPACT  ON  CSP. 

CM  #:  LA-83-2003 

STATUS:  ENHANCEMENT 
DESCRIPTION: 

PRESENT  ON-LINE  SYSTEM  AUDIT  TRAIL  CAPABILITY  (PAD  READOUT)  IS  DISK 
(MSGFIL)  DEPENDENT,  AND  LIMITED  TO  DISPOSITION  OF  ORIGINAL  DAN/MLN  AND 
THE  ASSOCIATED  TRANSACTION  RECORD.  SUBSEQUENT  MESSAGE  REENTRY  UNDER  A 
NEW  DAN/MLN  REQUIRES  ADDITIONAL  OPERATOR  INITIATED  'PAD  READOUT'  TO 
DETERMINE  THE  ULTIMATE  DISPOSITION  OF  THE  MESSAGE. 

THIS  PROBLEM  REQUIRES  RESTRUCTURE  OF  THE  PAD,  HENCE  A  NEW  RELEASE  WOULD 
BE  REQUIRED.  THIS  SHOULD  BE  SUBMITTED  TO  THE  CCB  FOR  EVALUATION. 

THIS  ENHANCEMENT  IS  PUT  ON  HOLD  PENDING  REPERCUSSIONS  OF  INSTALLATION 
OF  DUAL-DISK  RECORDING. 

CM  #:  LA-83-2005 

STATUS:  ENHANCEMENT 
DESCRIPTION: 

SUGGEST  'ON-CALL'  CAPABILITY  TO  RECONFIGURE  SITTE  SOFTWARE  TO  QUEUE 
SPECIFIED  ROUTING  INDICATORS  TO  A  UNIQUE  SOFTWARE  QUEUE  AND  DIRECT 
THIS  QUEUE  (INDEPENDENT  OF  ANY  OTHER  CSP  QUEUE)  TO  A  DESIGNATED 
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SU— 1652  FOR  WATCH  OFFICER  SCREENING.  THIS  SU-1652  DISPLAY  TERMINAL 
SHOULD  BE  LIMZTED  TO  PERFORM  THE  FOLLOWING  EVOLUTIONS: 

A  '  VFK  RELEASE'  AND  SYSGEN  OF  A  LINE  1  PILOT  CONTAINING  A  UNIQUE  RI 
B*  DIVERT  SELECTED  MESSAGES  TO  A  SPECIAL  QUEUE 
c’  PROVIDE  A  PRINTED  COPY  OF  ALL  MESSAGES  REVIEWED 
THIS  B4HANCEMHNT  IS  A  SITE  UNIQUE  REQUIREMENT.  EVALUATION  HAS  BEGUN 
FOR  USING  A  VFK  FOR  THIS  CAPABILITY. 


CM  #:  LA-83-2006 

STATUS:  ENHANCEMENT 


DESCRIPTION  * 

REQUEST  THAT  AN  INTERFACE,  COMMON  TO  OTHER  SYSTEMS  SUCH  AS  PDSC  AND  MAXI 
BE  INCLUDED  IH  THE  CSP  BASELINE  IN  EARLY  FY84. 

THIS  ENHANCEMENT  IS  AWAITING  INFORMATICS  EVALUATION. 


CM  #:  LA-83-2008 

STATUS:  PROBLEM  ON  HOLD 
DESCRIPTION: 

CRIITC  MODE  II  GATEWAY  TERMINATION  (E.G.  I/O  ERROR  TIMEOUTS)  ARE 
IDENTIFIED/WRITTEN  ON  A  DECWRITER  LOCATED  IN  AN  ADJOINING  COC  THAT 
MAINTAINS  OPERATIONAL  MAINTENANCE  RESPONSIBILITY  FOR  CSP  AND  FOUR  OTHER 
MAJOR  SYSTEMS  UNDER  CINCLANT  CONTROL.  CONSEQUENTLY,  ADP  PERSONNEL  THAT 
STAFF  THE  COC  CANNOT  DEVOTE  THEIR  COMPLETE  ATTENTION  TO  CSP  OPERATIONS 
AND  TIMELY  REPONSE  TO  GATEWAY  TERMINATION  DOES  NOT  ALWAYS  OCCUR.  VT-IOO 
IS  AN  INADEQUATE  SUBSTITUTE  FOR  HARDCOPY,  SEQUENTIAL  PRINTOUT  PROVIDED  BY 
THE  SYSTEM  DECWRITER  AND  DOES  NOT  ALWAYS  REFLECT  A  "TRUE"  SYSTEM  STATUS 
(E.G.  LINE  TIMEOUTS  AND  OTHER  IRREGULARITIES)  NEEDED  BY  THE  COMMUNICATIONS 
PERSONNEL. 

CM  #:  LA-83-2011 

STATUS:  ENHANCEMENT 
DESCRIPTION: 

THIS  IS  AN  ENHANCEMENT  TO  ALLOW  THE  FIXED  DISTRIBUTION  KEYS  TO  ALLOW  FOR 
PRECISE  DISSEMINATION  (I.E.  ACTION  ADDEES  AND  INFO  ADDEES).  THE  FD  VFKS 
CURRENTLY  PLACE  ALL  ADDEES  IN  THE  INFO  FIELD  AND  HAS  LIMITED  LANTCOM'S 
USE  AS  A  RESLT  OF  THE  HIGHLY  DIVERSE  INTERNAL  Cl NC LANT /Cl NC LANTFLT  STAFF 
AND  THE  INTRA-COMMAND  MESAGE  ROUTING  REQUIREMENTS. 


CM  #:  LA-83-2012 

STATUS:  ENHANCEMENT 
DESCRIPTION: 

THIS  ENHANCEMENT  WOULD  EXPAND  THE  ALLOWABLE  NUMBER  OF  ENTRIES  IN  THE 
FARM  TABLE  (160)  AND  THE  OSUPDT  TABLE  (140)  TO  280  ENTRIES  FOR  EACH  TABLE. 
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CM  #:  LA-83-2013 

STATUS:  ENHANCEMENT 
DESCRIPTION: 

THIS  ENHANCEMENT  WOULD  ARRANGE  LML  REPORTS  BY  DATE-TIME-GROUP  [DTG]  ORDER. 
THE  LML  IS  CURRENTLY  IN  THE  TIME  OF  RECEIPT  (TOR)  ORDER  WHICH  IS  RARELY 
USED  TO  IDENTIFY  MESSAGES.  THE  MOST  USED  IDENTIFIER  OR  REFERENCE  IS  THE 
ORIGINATOR  AND  DATE-TIME-GROUP.  A  DTG  ARRANGED  LML  REPORT  WOULD  BE  MORE 
LOGICAL  AND  ELIMINATE  EXCESSIVE  MAN  HOURS  IN  RESEARCHING  THE  CURRENT  LML 
REPORT. 

ECD:  30- JAN-84 

CM  #:  LA-83-2015 

STATUS:  PROBLEM  ON  HOLD 
DESCRIPTION: 

AN  ERROR  [U0002  QHAND  INV  PRB]  OCCURS  DURING  RESTART  SEQUENCE.  OTHER 
THAN  ERROR  AND  LOSS  OF  RECALL  CAPABILITY,  SYSTEM  REACTS  NORMALLY. 

LIMITED  RESEARCH  HAS  BEEN  DONE  TO  DETERMINE  THE  TOTAL  EFFECT  ON  THE  SYSTEM. 
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Figure  A-10  LANTCOM  Connectivity  Diagram 


All  incoming  messages  are  received  and  routed  by  MDC  operators; 
none  are  automatically  or  derivatively  routed. 

The  station  reliability  for  LANTCOM  including  both  hardware  and 
software  outages  is  approximately  99. 52. 

Future  Operations 

There  are  plans  to  implement  a  transmit/receive  interface  to  the 
OSIS  baseline  SUBLANT,  and  upgrade  the  CAMHS  interface  to  full  duplex. 
The  software  will  have  to  be  reconfigured  to  add  the  additional  lines 
and  queues  as  necessary  to  support  these  changes.  When  this  occurs, 
there  will  be  somewhat  of  an  increase  in  the  traffic  load  on  the  CSP. 

With  the  implementation  of  CSP  Release  2.3,  LANTCOM  plans  to 
convert  to  a  dumb  optical  character  reader  and  use  the  PLA  capabilities 
of  the  CSP. 

Site  Personnel 

The  CUBIC/CSP  on-site  representative  at  LANTCOM  is  Mr.  John  Strama, 
Informatics.  Mr.  Strama  works  closely  with  both  the  data  processing 
and  communications  staffs  of  CINCLANTFLT  in  his  daily  operations.  His 
primary  point  of  contact  is  CINCLANTFLT- J 291 . 


FTD,  Wright-Patterson  APB,  Ohio 


Site  Location 

CSP  was  installed  at  the  Foreign  Technology  Division  (FTD), 
Wright -Patter son  AFB,  Ohio  in  June,  1982. 

FTD  produces  scientific  and  technical  intelligence  (S&TI)  to 
provide  current  foreign  aerospace  technical  threat  assessments  for  use 
in  AFSC  systems  planning  an  acquistion.  In  addition,  FTD  is 
responsible  for  providing  foreign  aerospace  technological  data  and  data 
analysis  support  to  HQ  DSAF,  major  commands,  NASA,  agencies  of  the 
national  intelligence  community  and  R&D  support. 

CSP  supports  this  mission  by  providing  real  time  transmission  and 
reception  of  AUTODIN  message  communications. 

Equipment  Configuration 

The  CSP  is  currently  implemented  on  the  following  equipment: 

o  CPU  -  One  (1)  PDP-11/70  with  192K  memory 

o  System  Console  -  One  (1)  LA36  DECwriter 

o  Disk  Drives  -  Two  (2)  BR1538C 

o  Tape  Drives  -  Three  (3)  TU16  drives 

o  Multiplexer  -  One  (1)  32  channel  BR1569 

o  Line  Printers  -  Two  (2)  Dataproducts  2267,  600  1pm 

One  (1)  Dataproducts  2470,  1200  1pm 

o  AUTODIN  Interface  Device  -  One  (1)  TLC100 

o  Message  Distribution  Console  -  Two  (2)  OJ-389 

o  Other  Equipment  -  Two  (2)  ASR-28  paper  tape  readers 

One  (1)  CR-11  card  Reader 
Two  (2)  VT-52  terminals 

All  of  the  above  equipment  is  configured  as  one  operational  CSP. 
There  is  no  second  processor  or  set  of  peripherals  to  be  used  as  a 
backup.  The  current  backup  will  be  provided  manually  through  a  DSTE. 
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Software  Configuration 

Figure  A-ll  contains  a  site  report  extracted  from  Informatics 
Configuration  Management  System.  This  report  reflects  the  current 
software  release  level  for  this  site,  the  date  of  software  installation 
and  implementation  and  a  status  of  pending  releases.  Also  included  are 
any  site-unique  modules  developed  for  this  particular  site. 

Communicat ions  Configuration 

The  CSP  is  currently  connected  to  the  ASC  at  Gentile  for  online 
operations  with  the  Andrews  ASC  permanently  altrouted  to  the  same  line. 
In  the  event  of  a  circuit  outage,  the  Andrews  line  will  be  activated  on 
the  DSTE. 

There  are  no  other  local  tributaries  configured  as  direct  electrical 
links  at  this  time.  There  are,  however,  five  organizations  with 
computer  systems  which  are  serviced  with  a  magnetic  tape  interface.  A 
connectivity  diagram  is  illustrated  in  Figure  A-12. 

Current  Operations  Statistics 

FTD's  average  traffic  volume  and  CIM  rate  are  as  follows: 
o  Messages  transmitted  -  1,825  per  month 
o  Messages  received  -  25,000  per  month 
o  Line  blocks  transmitted  -  40,000  per  month 
o  Line  blocks  received  -  900,000  per  month 
o  CIM  rate  -  1.45Z 

Given  this  traffic  volume  and  the  capacity  of  the  message  file,  it 
is  anticipated  that  the  online  message  storage  capacity  will  be 
approximately  35  days. 

Since  there  are  no  automated  backside  processors,  no  messages  are 
derivatively  routed  and  all  messages  are  manually  received  by  the  MDC 
operators.  The  MDC  clerk  determines  routing  for  all  incoming  messages 
and  places  each  message  on  selected  output  queues  for  either  hardcopy 
or  mag-tape  distribution.  Mag-tape  messages  are  altrouted  to  the 
intercept  tape  during  normal  operation  of  CSP.  Once  daily,  these 
messages  are  placed  on  their  respective  mag-tapes  and  hand-carried  to 
the  responsible  organizations. 


SITE:  FTD  (FT) 


RELEASE:  2.2C2 
STATUS:  OPERATIONAL 


DATE  OF  INSTALLATION: 


01 -SEP-82 


11 -MAR-83 


REMARKS:  RELEASE  2.3  WAS  INSTALLED  AND  IS  AWAITING  OPERATIONAL  IMPLEMENTATION 
PENDING  CIRCUIT  RECONFIGURATION  BY  THE  ASC 


UNIQUE  MODULES: 

MODULES:  HD 2C ON. MAC 
IDENT:  V22FT1 

DESCRIPTION: 

ENABLES  PAPER  TAPE  READER 


OUTSTANDING  PROBLEM  REPORT: 


Figure  A-ll  FTD  Configuration  Status 


future  Operation! 

There  are  plana  to  procure  one  more  OJ-389  and  an  additional 
TLC100.  Also,  at  aome  point  in  the  future  the  BR1538C  disk  drives  will 
be  upgraded  to  BR1538D  drives,  increasing  the  capacity  to  300  MB  each. 

The  pr  -blem  with  no  CSP  backup  will  be  alleviated  by  the 
procurement  of  an  additional  PDP-11/70  system  as  soon  as  it  is 
available. 

Site  Personnel 

There  are  currently  no  contractor  personnel  on-site  at  FTD.  All 
on-site  maintenance  ia  provided  by  FTD  personnel  for  identification  of 
problems  and  routine  table  maintenance.  Problems  will  be  resolved  by 
the  centralized  development  staff  in  Bellevue  and  solutions  will  be 
communicated  to  FTD  personnel  for  implementation. 


ADCOM,  Colorado  Springs ,  Colorado 

Site  Locations 

CSP  was  installed  at  HQ  Air  Defense  Command,  Cheyenne  Mountain 
Complex,  Colorado  Springs,  Colorado  in  August,  1982,  and  was  placed 
online  in  October,  1982. 

The  NORAD/ADCOM  community  provides  surveillance,  detection  and 
early  warning  for  the  North  American  continent  and  its  perimeters.  The 
CSP  will  support  this  mission  by  providing  real-time  transmission  and 
reception  of  ADTODIN  message  comnunications. 

Equipment  Configuration 

The  CSP  is  currently  implemented  on  the  following  hardware  for  the 
primary  system: 

o  CPD  -  One  (1)  PDP-11/ 70  with  256K  memory 

o  System  Console  -  One  (1)  LAI 20  DECwriter 

o  Disk  Drives  -  Three  (3)  BR1538D  (shared) 

One  (1)  RL01 

o  Tape  Drives  -  Two  (2)  TE16  (shared) 

One  (1)  TE16 

o  Multiplexer  -  One  (1)  BR1731 

o  Line  printers  -  One  (1)  LP11VA  (shared) 

One  (1)  LP11VA 

o  ADTODIN  Interface  Device  -  Two  (2)  TLC100  (shared) 
o  Message  Distribution  Console  -  Three  (3)  OJ-389  (shared) 


Other  Equipment  -  One  (1)  PC 11  Paper  Tape  Reader/Punch 
(shared) 

One  (1)  CR11  Card  Reader  (shared) 

One  (1)  VT100  terminal 

The  backup  system  is  configured  exactly  the  same  as  the  primary 
system,  so  full  redundancy  is  provided.  Those  items  listed  as  shared 
are  switchable  between  the  two  processors  through  a  DT07  unibus  switch. 
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Software  Configuration 

Figure  A-13  contains  a  site  report  extracted  from  Informatics 
Configuration  Management  System.  This  report  reflects  the  current 
software  release  level  for  this  site,  the  date  of  software  installation 
and  implementation  and  a  status  of  pending  releases.  Also  included  are 
any  site-unique  modules  developed  for  this  particular  site. 

CoMBunicationa  Configuration 

ADCOM's  CSP  has  links  to  two  ASCs,  McClellan  and  Tinker.  In 
addition,  there  is  a  link  to  the  NCMC  command  post  which  is  configured 
as  a  Mode  II  circuit. 

A  connectivity  diagram  is  presented  in  Figure  A-14. 

Current  Operations  Statistics 

ADCOM's  average  traffic  volume  and  CIM  rate  are  as  follows: 
o  Messages  transmitted  -  1,800  per  month 
o  Messages  received  -  35,000  per  month 
o  CIM  rate  -  1.302  average 

Given  this  traffic  volume  and  the  capacity  of  the  message  file,  it 
is  anticipated  that  the  on-line  message  storage  capacity  will  be 
approximately  40  days. 

Future  Operations 

There  are  no  known  changes  to  the  planned  hardware  configuration  at 
ADCOM.  However,  as  soon  as  CSF  Release  3.0  is  implemented,  ADCOM  plans 
to  use  the  remote  OJ-389  dissemination  capability.  The  actual  mode  of 
operation,  however,  is  unknown  at  this  time. 

8ite  Personnel 

The  CUBIC /CSP  on-site  representative  at  ADCOM  is  Mr.  Dale  Pease, 
Informatics.  He  interfaces  on  a  daily  basis  with  the  ADCOM 
communications  staff. 


SITE:  ADCOH  (AD) 


RELEASE:  2.3A 

STATUS:  OPERATIONAL  02-AUG-83 
DATE  OF  INSTALLATION:  25-JUL-83 
REMARKS:  NONE 


UNIQUE  MODULES: 
NONE 


******************************************************************************** 

OUTSTANDING  PROBLEM  REPORT: 

CM  #:  AD-82-0001 

STATUS:  ENHANCEMENT 
DESCRIPTION: 

REQUEST  GATEWAY/SOFTWARE  BE  DEVELOPED  FOR  THE  FOLLOWING  CARD  PUNCH: 

A)  MANUFACTURER:  DECISION  DATE 

B)  MODEL:  8010-80  CARD  PROCESSOR 

C)  OPTIONS:  WITH  BINARY  CAPABILITIES 

THIS  ENHANCEMENT  IS  AWAITING  REQUIREMENTS  DEFINITION. 

CM  #:  AD-83-2004 

STATUS:  PROBLEM  ON  HOLD 
DESCRIPTION: 

MESSAGES  NOT  RECOGNIZING  ALL  AIGS.  MESSAGES  RECEIVED  WITH  FOUR  AIGS 
IN  FORMAT  LINES  SEVEN  AND/OR  EIGHT.  FARM  DROPPED  THE  SECOND  AND  ROUTED 
THE  THIRD  AIG.  THE  FIRST  AND  FOURTH  WERE  NOT  IN  THE  DATA  BASE. 

CM  #:  AD-83-2007 

STATUS:  PROBLEM  ON  HOLD 
DESCRIPTION: 

ALROUTED  MSGS  RECEIVED  FROM  ANOTHER  STATION  ARE  ROUTED  TO  THE  'CAR'  QUEUE. 
WHEN  THE  STATION  IS  RETURNED  TO  SERVICE,  THE  'CAR'  QUEUE  IS  ALTROUTED  TO 
THE  DIN  (AUTODIN)  QUEUE.  IF  THE  ORIGINAL  ALTROUTED  MESSAGE  HAD  AN  LMF  OF 
(CT),  THE  ASC  WILL  GIVE  AN  INVALID  HEADER  REJECT  BECAUSE  THERE  IS  NO  CARD 
COUNT  IN  THE  REINTRODUCED  MESSAGE. 

CM  #:  AD-83-2008 

STATUS:  PROBLEM  ON  HOLD 
DESCRIPTION: 

MSG  ROUTING  INDICATORS  PRESCRIBED  IN  ACP  117  ARE  NOT  ABLE  TO  BE  ENTERED 
INTO  THE  PLARI  BY  CLASSIFICATION;  I.E.  'UNCLAS'  OR  'CLASSIFIED'  AS  TO 
WHAT  THE  DISTANT  BID  CAN  RECEIVE.  AT  PRESENT,  ONLY  CLASSIFIED  ROUTING 
INDICATORS  ARE  ENTERED  IN  THE  FILE.  BY  INSERTING  'UNCLAS'  R/I'S  INTO 
THE  PLARI,  THE  CHANCE  OF  SENDING  THE  WRONG  R/I  IS  MAGNIFIED. 


Figure  A-13  ADCOM  Configuration  Status 
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HQ  CINCPAC,  Camp  H.M.  Smith,  Hawaii 


Site  Location 

CSP  was  installed  at  HQ  Commander-in-chief  Pacific  in  July  1979. 
This  installation  was  reaccredited  by  DIA  and  DCA  in  July  1982.  The 
occassion  for  this  reaccreditation  was  the  implementation  of  the  Fully 
Automated  Routing  of  Messages  (FARM)  software  package  developed  by  the 
CSP  programmer  assigned  to  CINCPAC.  This  software  package  will  be 
included  in  the  CUBIC/CSP  baseline,  and  will  be  distributed  to  CSP  users 
as  their  systems  are  updated  with  the  current  baseline. 

The  Pacific  Command  (PACOM)  area  consists  of  approximately  96 
million  square  miles  and  contains  two-thirds  of  the  world's  population. 
The  type,  level  and  degree  of  threat  to  U.S.  national  interest  ranges 
from  the  strategic  nuclear  forces  of  the  Soviet  Union  to  the 
guerrilla/insurgency  threat  in  the  Southern  and  Southeast  Asian  areas. 
The  mission  of  the  Commander-in-chief,  Pacific  (CINCPAC),  is  "To 
maintain  the  security  of  PACOM  and  defend  the  United  States  against 
attack  through  the  Pacific  Ocean;  to  support  and  advance  the  national 
policies  and  interests  of  the  United  States  and  discharge  U.S.  military 
responsibilities  in  the  Pacific,  Far  East,  Southeast  and  South  Asia;  to 
prepare  plans,  conduct  operations  and  coordinate  activities  of  the 
forces  of  the  PACOM  in  consonance  with  directives  of  higher  authority." 

CSP  provides  DSSCS  Communications  Support  for  transmission  and 
reception  of  real-time  AUTODIN  messages  in  support  of  CINCPAC's  mission. 
In  addition,  the  CSP  functions  as  a  front-end  processor  for  the  PACOM 
Data  Systems  Center  (PDSC)  system,  which  directly  support  CINCPAC's 
intelligence  analysts.  The  PDSC  computer  system  is  a  derivative  of  the 
MAXI  system. 

Equipment  Configuration 

The  CSP  at  CINCPAC  is  currently  implemented  on  the  following 
hardware  for  the  primary  system: 

o  CPU  -  One  (1)  PDP-11/ 70  with  256K  memory 

o  System  console  -  One  (1)  LA36  DECwriter 

o  Disk  drives  -  Three  (3)  BR1538D  (shared) 

o  Tape  drives  -  Two  (2)  TE10 

Three  (3)  TU45  (shared) 
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o  Multiplexer  -  One  (1)  36  channel  BR1569 

o  Line  printers  -  One  (1)  LP11  RA  (shared) 

Two  (2)  IT  Model  4010  (shared) 

One  (1)  TT  Model  4030  (shared) 

o  AUTODIN  interface  device  -  Two  (2)  INTEQ  (shared) 

o  Message  distribution  console  -  Three  (3)  OJ-389  (shared) 

o  Other  equipment  -  One  (1)  VT52  Terminal  (shared) 

Four  (4)  Paper  Tape  Reader/Punch 
(shared) 

One  (1)  Card  Reader  (shared) 

One  (1)  Unibus-Unibus  link 
One  (1)  OCR  (shared) 

The  backup  system  is  configured  identically  to  the  primary.  Those 
items  listed  as  "shared"  above  are  switchable  between  the  two 
processors.  Additionally,  individual  circuits  terminating  in  the  BR1569 
multiplexer  are  switchable  between  both  processors. 

Software  Configuration 

Figure  A-15  contains  a  site  report  extracted  from  Informatics 
Configuration  Management  System.  This  report  reflects  the  current 
software  release  level  for  this  site,  the  date  of  software  installation 
and  implementation,  and  a  status  of  pending  releases.  Also  included 
are  any  site  unique  modules  developed  for  this  particular  site. 

Communications  Configuration 

The  CSP  is  dual-homed  to  McCellan  and  Wahiawa  ASCs  for  online 
tributary  operations,  DSSCS  only.  The  only  backside  tributary  at 
CINCPAC  is  the  PDSC  system,  a  derivative  of  the  MAXI  system. 

A  connectivity  diagram  for  CINCPAC  is  presented  in  Figure  A-16. 

Current  Operations  Statistics 

o  Messages  transmitted  -  1,500  per  month 

o  Messages  received  -  53,600  per  month 
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SITE:  CINCPAC  (PD) 


RELEASE:  2.3A 

STATUS:  OPERATIONAL  06-SEP-83 
DATE  OF  INSTALLATION :  22-AUG-83 
REMARKS:  NONE 


******************************************************************************** 
UNIQUE  MODULES: 

MODULES:  AUTCON.MAC 
IDENT:  V23PD1 

DESCRIPTION: 

SITE  UNIQUE  MODULE  TO  REPLACE  TLCCON  AS  THE  AUTODIN  GATEWAY.  THIS  IS 
REQUIRED  TO  INTERFACE  THE  INTEQ  DEVICE. 

MODULES:  COMMLC.MAC 
IDENT:  V23PD1 

DESCRIPTION: 

MODIFIED  TO  ALLOW  THE  DCT  AND  POSC  LINES  TO  BE  TURNED  ON  AND  OFF. 

MODULES:  CSPSKD.MAC 
IDENT:  V23PD1 

DESCRIPTION: 

MODIFIED  TO  ALLOW  TIME  SET  BY  SITE  FOR  RUN  TIME  PLS 

MODULES:  DCTRDR.MAC 
IDENT:  V23PD1 

DESCRIPTION: 

SITE  UNIQUE  MODULE  TO  READ  MESSAGES  FROM  A  GENSER  ONLY  DCT  2000  AND  PLACE 
THEM  INTO  A  FILES-11  FILE  FOR  DIRECT  TRANSFER  TO  PDSC. 

MODULES:  DCTREF.MAC 
IDENT:  V23PD1 

DESCRIPTION: 

SITE  UNIQUE  MODULE  TO  REFORMAT  MESSAGES  FROM  THE  DCT  LINE  FOR  TRANSMISSION 
TO  PDSC. 

MODULES:  DMC  .MAC 
IDENT:  V23PD1 

DESCRIPTION: 

SITE  UNIQUE  MODULE  TO  ALLOW  AN  OPERATOR  COMMAND  TO  CONTROL  THE  TRANSFER 
OF  ANY  FILE  TO  PDSC. 
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MODULES:  DMCDRV.HAC 
IDENT:  V23PD1 

DESCRIPTION: 

SITE  UNIQUE  MODULE  TO  SCAN  THE  DISK  FOR  ANY  FILES  TO  BE  TRANSFERED  TO  PDSC. 
THIS  TASK  NOTIFIES  DMCGTY  TO  START  THE  TRANSFER. 

MODULES:  DMCGTY. MAC 
IDENT:  V23PD1 

DESCRIPTION: 

SITE  UNIQUE  GATEWAY  TO  PULL  MESSAGES  FROM  A  FILES-11  FILE  TO  TRANSFER  TO 
THE  PDSC  SYSTEM.  THIS  GATEWAY  USES  THE  UNIVAC  TERMINAL  PROTOCAL  ON  THE 
BR1569. 

MODULES:  DSPV52.MAC 
IDENT:  V23PD1 

DESCRIPTION: 

BASELINE  MODIFICATION  TO  DISPLAY  THE  STATUS  OF  THE  DCT  RECEIVE  LINE,  AND 
REFORMATTER;  AND  THE  DMC  DRIVER  AND  GATEWAY  TO  PDSC. 

MODULES:  INTGEN.MAC 
IDENT:  V23PD1 

DESCRIPTION: 

MODIFIED  TO  DISPLAY  PDSC  CIRCUIT  STATUS 

MODULES:  MSMSN  .MAC 
IDENT:  V23PD1 

DESCRIPTION: 

POSC  UNIQUE  ERROR  MESSAGE  FILE. 

MODULES:  MSSGWY.MAC 
IDENT:  V23PD1 

DESCRIPTION: 

SITE  UNIQUE  GATEWAY  TO  PLACE  MESSAGES  INTO  A  FILES-11  FILE  FOR  USE  BY  THE 
DMCGTY  SOFTWARE. 

MODULES:  OEEGWY.MAC 
IDENT:  V23PD1 

DESCRIPTION: 

SITE  UNIQUE  GATEWAY  TO  PLACE  KESSAGES  INTO  A  FILES-11  FILE  FOR  USE  BY 
THE  DMCGTY  SOFTWARE. 

MODULES:  QHAND  .MAC 
IDENT:  V23PD1 

DESCRIPTION: 

MODIFIED  FOR  AUTCON  CRITIC  HANDLING 

MODULES:  RDPGWY.MAC 
IDENT:  V23PD1 

DESCRIPTION: 

MODIFIED  TO  PRINT  AN  ADDITIONAL  LINE  AT  THE  TOP  OF  EVERY  ICSSAGE 
CONSISTING  OF  'SWO'  AND  'DISTRO'. 
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MODULES:  TA  .MAC 
IDENT:  V22PD1 

DESCRIPTION: 

SITE  UNIQUE  HANDLER  TO  DRIVE  THE  MOD  40  PRINTERS  THROUGH  THE  BR156S 
ASCII  ROM. 


******************************************************************************** 

OUTSTANDING  PROBLEM  REPORT: 

CM  #:  PD -83-2002 
STATUS:  UNDER  ANALYSIS 
DESCRIPTION: 

WHEN  AN  OUTGOING  MSG  IS  GENERATED  IN  OTHER  THAN  DD-173  FORMAT  (I.E 
MESSAGE  RECAL  FOR  READDRESSABLE  FOR  SYSTEM  INPUT,  THE  OSSN  MUST  BE 
INSERTED  MANUALLY  BE  THE  OPERATOR.  IF  THE  OPERATOR  USES  THE  NEXT 
AVAILABLE  OSSN,  THAT  OSSN  WILL  BE  DUPLICATED  ON  THE  MESSAGE  PROCESSED 
BY  PLA. 

ECD:  1 -NOV-83 
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CINCPAC  Connectivity  Diagram 


o 


CIM  Rate  -  2Z 


The  CSP  ia  able  to  maintain  approximately  60  days  of  online 
atorage.  CINCPAC  ha  a  been  able  to  maintain  a  low  CIM  rate  due  to  the 
extenaive  format  and  aecurity  checks  performed  by  the  CSP. 

Approximately  75Z  of  the  incoming  messages  are  derivatively  routed 
to  PDSC.  Of  the  remainder,  95Z  are  automatically  routed  by  the  FARM 
software.  The  Message  Distribution  Clerk  routes  the  rest. 

The  reliability  for  CINCPAC  including  both  hardware  and  software 
outages  is  approximately  99Z. 

Future  Operations 

The  existing  software  between  the  CSP  and  PDSC  was  written  and 
installed  by  non-informatics  contractor  personnel.  This  software  will 
be  redesigned  by  Informatics  personnel,  reinstalled  and  reaccredited. 
This  will  be  accomplished  on  an  interim  basis  to  be  followed  by  a 
standard  baseline  gateway  in  the  future. 

Site  Personnel 

-  There  are  no  CUBIC/CSP  on-site  representatives  at  CINCPAC. 
Informatics  facility  at  Bellevue  coordinates  with  other  contractor 
personnel  and  the  cossnunicatious  staff  of  CINCPAC  to  resolve  system 
problems . 
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RKDCOM,  MacDill  AFB  Florida 


Site  Location 

CSP  was  installed  at  REDCOM,  MacDill  AFB,  Florida  in  September, 
1982  and  supports  both  USREDCOM  and  USCENTCOM  activities. 

CSP  'a  primary  mission  is  to  provide  continuous  message  handling 
support  for  both  USREDCOM  and  USCEITTCOM  personnel.  These  agencies  both 
have  a  mission  of  rapid  deployment  to  support  contingencies.  Major 
exercises  are  conducted  and  supported  by  the  two  major  commands  using 
the  CSP.  The  CSP  hardware  itself  is  operated  by  USREDCOM  personnel. 

Equipment  Configuration 

The  CSP  at  REDCOM  is  currently  implemented  on  the  following 
hardware  for  the  primary  system: 

o  CPU  -  One  (1)  PDP-11/ 70  with  51 2K  memory 

o  System  Console  -  One  (1)  LA36  DEC writer 

o  Disk  drives  -  Two  (2)  BR1538D  (shared) 

Two  (2)  RL02  (shared) 

o  Tape  drives  -  Three  (3)  TE16 

o  Multiplexer  -  One  (1)  BR1731 

o  Line  Printer(s)  -  One  (1)  LP11  (shared) 

o  AUTODIN  Interface  Device  -  Two  (2)  TLC100  (shared) 

o  Message  Distribution  Console  -  Two  (2)  OJ-389  (shared) 

o  Other  Equipment  -  One  (1)  VT100  terminal 

One  (1)  MOD-40  remote  printer  (shared) 

The  backup  system  is  configured  almost  identically  to  the  primary. 
Those  items  listed  as  "shared"  above  are  switchable  between  the  two 
processor. 

Software  Configuration 

Figure  A-17  contains  a  site  report  extracted  from  Informatics 
Configuration  Management  System.  This  report  reflects  the  current 
software  release  level  for  this  site,  the  date  of  software  installation 
and  implementation  and  a  status  of  pending  releases.  Also  included  are 
any  site-unique  modules  developed  for  this  particular  site. 
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SITE:  REDCOM  (RE) 


RELEASE:  2.3A 

STATUS:  OPERATIONAL  15-AUG-B3 
DATE  OF  INSTALLATION:  17-SEP-82 
REMARKS:  NONE 


*******************************************************************! 

UNIQUE  MODULES: 

MODULES:  NSACON.MAC 
IDENT:  V22RE1 

DESCRIPTION: 

THIS  IS  A  COPY  OF  MD2C0N  TO  SUPPORT  A  ZICON  CIRCUIT  TO  NSA. 

MODULES:  RDFCON.MAC 
IDENT:  V22RE1 

DESCRIPTION:  . 

THIS  IS  A  COPY  OF  MD2C0N  TO  SUPPORT  A  MODE  II  CIRCUIT  AT  RDJTF 


******************************************************************************** 

OUTSTANDING  PROBLB1  REPORT: 

CM  #:  RE-83-2029 

STATUS:  ENHANCEMENT 
DESCRIPTION: 

LML  LISTING  FOR  RECEIVE  LINE  DOESN'T  EXIST. 

ECO:  NOT  ESTABLISHED 

CM  #:  RE-83-2033 

STATUS:  UNDER  ANALYSIS 
DESCRIPTION: 

A  MSG  NAS  GENERATED  FOR  BOTH  THE  AUTODIN  AND  FARM  QUEUES.  THE  MSG  APPEARED 
TO  GO  TO  BOTH  QUEUES  BUT  NAS  ACTUALLY  REJECTED  BY  THE  ASC  PROBABLY  FROM 
THE  TLC.  THE  MSG  ON  THE  OPERATOR'S  CONSOLE  ONLY  STATES  "1004  —  TTINK  - 
MSG  RM  SY  ASC".  THIS  ERROR  NAS  NRITTEN  TO  THE  REF  RECORD  AND  THE  MSG  NAS 
RETURNED  TO  THE  SERVICE  QUEUE.  THE  IMAGE  THAT  NAS  THEN  PUT  ON  THE  FARM 
QUEUE  NAS  ALSO  REJECTED  BECAUSE  FARM  WAS  UNABLE  TO  DETERMINE  THE  ROUTING 
OF  THE  MSG.  SINCE  THIS  MSG  NAS  ALSO  WRITTEN  IN  THE  REF  RECORD,  THE 
SERVICE  CLERK  HAD  NO  INDICATION  THAT  THE  MSG  NAS  REJECTED  BY  THE  ASC, 
CAUSING  AN  EXTENSIVE  DELAY. 

ECO:  2-1-83 


Figure  A-17  REDCOM  Configuration  Status 
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inications  Configuration 


The  REDCOM  CSP  is  dual-honed  with  links  to  Albany  and  Tinker  ASCs. 
There  is  a  Z1C0N  circuit,  both  transnit  and  receive.  Another  renote 
communications  line  consists  of  an  OJ-389  message  distribution  terminal 
in  the  CENTCOM  communications  center. 

The  backside  computer  interface  at  REDCOM  is  a  MAXI  system  for 
analyst  support. 

A  connectivity  diagram  for  REDCOM  is  presented  in  Figure  A-18. 
Currant  Operations  Statistics 

REDCOM' s  average  traffic  volume  and  CIM  rate  are  not  available  at 
this  time. 

The  majority  of  incoming  mesaages  are  received  and  routed 
automatically  by  the  FARM  software.  The  bulk  of  these  messages  are 
routed  directly  to  the  MAXI  system  for  delivery  to  various  USREDCOM  and 
USCENTCOM  users. 

Future  Operations 

When  the  CSP  Remote  Conunications  Center  Capability  is  completed, 
CENTCOM  will  utilize  their  OJ-389  terminal  as  a  full  comsninications 
terminal  with  CSP  separating  the  traffic  destined  for  CENTCOM  from  that 
destined  for  REDCOM.  Also,  outgoing  traffic  will  be  segregated  by  OSRI 
to  determine  release  authorisation  and  error  correction. 

Site  Personnel 

The  CUBIC/CSP  on-site  representative  at  LANTCOM  is  Mr.  Richard 
Arab,  PRC.  Mr.  Arab  works  closely  with  both  the  data  processing  and 
communications  staffs  of  USREDCOM  and  USCENTCOM  in  his  daily 
operations.  His  primary  point  of  contact  is  REDC0M/J2-PR. 


Figure  A-18  REDCOM  Connectivity  Diagram 


USAREUR,  Heidelberg,  Germany 


Site  Location 

CSP  was  installed  at  HQ  US  Army  Europe  (USAREUR),  Heidelberg 
Germany  in  January,  1983  and  is  being  operated  by  U.S.  Army  data 
processing  personnel.  It  is  located  in  three  relocatable  vans  and  is 
designed  for  use  in  a  tactical  environment. 

CSP's  primary  mission  at  HQ  USAREUR  is  to  provide  continuous 
message  handling  support  for  the  Relocatable  Army  Processors  for 
Intelligence  Data  Europe  (RAP1DE) .  RAPIDE  is  the  intelligence 
automation  upgrade  that  is  specifically  designed  to  meet  the  needs  of 
the  Echelon-Above-Corps  (EAC)  intelligence  mission  in  peacetime,  crisis 
and  war.  The  goal  of  RAPIDE  is  to  help  intelligence  operations  by 
getting  needed  messages  to  the  correct  analyst  more  quickly,  giving 
analysts  access  to  all  required  information,  providing  decision  aids  to 
help  synthesize  the  data,  and  helping  the  analyst  produce  more  product 
in  a  given  time. 

Equipment  Configuration 

The  CSP  at  USAREUR  is  currently  implemented  on  the  following 
hardware  for  the  primary  system: 

o  CPU  -  One  (1)  PDP-11/ 70  with  960K  memory 

o  System  Console  -  One  (1)  LA36  DECWRITER 

o  Disk  drives  -  Five  (5)  BR1538B 

o  Tape  drives  -  Two  (2)  TE16 

o  Multiplexer  -  One  (1)  BR1569 

o  Line  printer  -  One  (1)  LP11RA 

o  AUTODIN  Interface  Device  -  One  (1)  TLC100 

o  Message  Distribution  Console  -  One  Cl)  OJ-389 

o  Other  Equipment  -  One  (1)  VT100  terminal 

One  (1)  TLC100  for  MAXI  link 

There  is  no  backup  system  per  se  at  USAREUR.  There  is  however 
another  van  available  with  similar  equipment  that  can  be  used  in  the 
event  that  the  primary  CSP  equipment  is  down. 
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Software  Configuration 


Figure  A-19  contains  a  site  report  extracted  from  Informatics 
Configuration  Management  System.  This  report  reflects  the  current 
software  release  level  for  this  site,  the  date  of  software  installation 
and  implementation  and  a  status  of  pending  releases.  Also  included  are 
any  site-unique  modules  developed  for  this  particular  site. 

Conmunieationa  Configuration 

The  USAREUR  CSP  is  single-homed  with  a  link  to  Firmasens  ASC.  The 
backside  computer  interface  at  USAREUR  is  a  standard  MAXI  but  it  is 
configured  with  back-to-back  TLClOOs  to  provide  synchronous 
communications  and  message  transmission  control. 

A  connectivity  diagram  for  USAREUR  is  presented  in  Figure  A-20. 
Currant  Operations  Statistics 

USAREUR' a  average  traffic  volume  and  CIM  rate  are  not  available  at 
this  time.  The  average  traffic  volume  is  not  very  high  but  the  site  is 
equipped  to  handle  a  large  increase  in  volume  as  a  result  of  contingency 
situations. 

Most  incoming  messages  are  automatically  or  derivatively  routed, 
with  a  small  amount  being  handled  by  the  message  distribution  clerk. 

Future  Operations 

There  are  plans  to  replace  the  current  PUP  11/70  van  mounted  system 
with  a  POP  11/44  in  a  larger  trailer.  This  would  also  involve 
upgrading  the  BR1538B  disk  drives  to  the  newer  DEC  RA60  disks.  Another 
enhancement  foreseen  is  to  dual -ho me  to  Pirmasens  and  Croughten  ASCs 
which  would  provide  more  reliability. 

Site  Personnel 

There  is  no  full-time  on-site  support  representative  at  HQ  USAREUR. 
Part  time  support  has  been  provided  at  the  rate  of  one-third  time.  The 
CUBIC/CSP  on-site  representative  providing  this  service  is  Mr.  Eric 
Bruno  who  is  based  at  Ramstein  AB,  Germany.  The  additional  support  has 
been  provided  over  the  telephone  by  Mr.  Bruno.  Mr.  Bruno  works  closely 
with  the  systems  staff  of  USAREUR  in  his  daily  operations.  Bis  primary 
point  of  contact  is  HQ  USAREUR /ODCSI-SYS. 
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SITE:  USAREUR  (UR) 


RELEASE:  2.3A 

STATUS:  OPERATIONAL  01 -SEP-83 
DATE  OF  INSTALLATION:  01 -SEP-83 
REMARKS:  NONE 


UNIQUE  MODULES: 
NONE 


OUTSTANDING  PROBLEM  REPORT: 
NONE 


Figure  A-19  USAEUR  Configuration  Status 


USAFE  TFC ,  Germany 


Site  Loeetion 

CSF  vas  originally  installed  at  HQ  USAFE  Tactical  Fusion  Center 
(TFC),  Germany  in  April,  1983  as  part  of  the  Operational  Applications 
of  Special  Intelligence  Systems  (OASIS)  project.  It  was  installed  by 
another  contractor  under  contract  to  ESD.  In  July,  1983  it  was 
upgraded  to  a  later  release  of  CSP  software  and  accepted  by  the 
government.  In  September  1983,  Informatics,  as  part  of  the  CUBIC 
program  reinstalled  CSP  release  2.3  baseline  software  but  maintained 
the  site-unique  CSP/MAXI  interface  installed  by  the  original 
contractor.  This  software  is  currently  undergoing  evaluation  by 
Informatics. 

CSP  provides  continuous  message  handling  support  for  the  OASIS 
project.  It  provides  the  Tactical  Fusion  Center  with  access  to  the 
AUTODIN  network  and  interfaces  to  the  MAXI  system  for  analyst  support. 

Equipment  Configuration 

The  CSP  at  the  TFC  is  currently  implemented  on  the  following 
hardware  for  the  primary  system: 

o  CPU  -  One  (1)  PDP-11/70 

o  System  Console  -  One  (1)  LA36  DECwriter 

o  Disk  Drives  -  Three  (3)  BR1538D 

o  Tape  drives  -  Two  (2)  TE16 

o  Multiplexer  -  One  (1)  BR1731 

o  Line  printers  -  One  (1)  LP11 

o  AUTODIN  Interface  Device  -  One  (1)  Analytics  TLC100 

o  Message  Distribution  Console  -  One  (1)  OJ-389 

o  Other  Equipment  -  One  (1)  VT100  terminal 

One  (1)  PCL11-B  Communication  Device 

The  backup  system  is  configured  almost  identically  to  the  primary. 
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Software  Configuration 

Figure  A-21  contains  a  site  report  extracted  from  Informatics 
Configuration  Management  System.  This  report  reflects  the  current 
software  release  level  for  this  site,  the  date  of  software  installation 
and  implementation  and  a  status  of  pending  releases.  Also  included  are 
any  site-unique  modules  developed  for  this  particular  site. 

Communications  Configuration 

The  USAFE  TFC  is  single-homed  with  a  link  to  Pirmasens  ASC.  The 
backside  computer  interface  at  the  TFC  is  configured  as  a  MAXI  system 
interfaced  through  a  PCLll  interface  device  using  the  Inter  Computer 
Communications  (ICC)  Gateway  software.  This  ICC  software  also 
inter-connects  two  other  processors  which  include  IDHSC-II  and  OPSCOM 
capabilities. 

A  connectivity  diagram  for  the  TFC  is  presented  in  Figure  A-22. 

Current  Operations  Statistics 

The  average  traffic  volume  and  CIM  rate  for  the  OSAFE  TFC  are  not 
available  at  this  time.  Incoming  messages  are  automatically  or 
derivatively  routed  to  the  MAXI  system.  A  small  percentage  of  messages 
are  handled  by  the  message  distribution  clerk. 

Future  Operations 

The  current  ICC/PCL11  interface  to  MAXI  is  being  evaluated  for 
possible  incorporation  into  the  baseline.  It  is  anticipated  that  this 
capability  will  not  be  baselined  but  rather  treated  as  a  site  unique 
interface.  If  possible,  this  interface  will  be  replaced  by  a  standard 
CSP/MAXI  gateway  at  some  point  in  the  future. 

Site  Personnel 

The  CUBIC/CSP  on-site  representative  at  LANTCOM  is  Mr.  John 
Konopik,  Informatics.  Mr.  Konopik  works  closely  with  both  the  HQ  USAFE 
TFC  staff  in  his  daily  operations.  His  primary  point  of  contact  is 
7011  CSF  USAFE/ADW. 


SITE:  USAFE  TFC  (TF) 


RELEASE:  2.2C2 

STATUS:  OPERATIONAL  15-JUN-83 

DATE  OF  INSTALLATION:  21 -OCT-83 

REMARKS:  RELEASE  2.3  WAS  INSTALLED  AND  IS  BEING  TESTED  PRIOR  TO  ON-LINE  OPERATION 

******************************************************************************** 

UNIQUE  MODULES: 

NONE 

******************************************************************************** 
OUTSTANDING  PROBLEM  REPORT: 

NONE 


Figure  A-21  USAFE  TFC  Configuration  Status 


Figure  A-22  TFC  Connectivity  Diagram 


REPRODUCED  AT  GOVERNMENT  EXPENSE 


MISSION 
of 

Rome  Air  Development  Center 

RAVC  plant*  and  executes  KueoAch,  development,  tut  and 
selected  acquisition  programs  in  Support  of  Command,  Control 
Communications  and  Intelligence  (C3I)  activities.  Technical 
and  engineering  support  within  areas  of  technical  competence 
is  provided  to  ESP  Program  0 ibices  (POa)  and  other  ESP 
elements.  The  principal  technical  mission  areas  are 
communications,  electromagnetic  guidance  and  control,  sur¬ 
veillance  o f  ground  and  aerospace  objects,  intelligence  data 
collection  and  handling,  information  system  technology, 
ionospheric  propagation,  solid  state  sciences,  microwave 
physics  and  electronic  reliability,  maintainability  and 
compatibility. 


